Fastmcp released three patches in ten minutes for one bug

Fastmcp published three releases in ten minutes on September 8, all fixing the same bug in different places.

The first, v4.20.4, moved tool progress notifications onto a request-scoped notifier, so a running call only hears about its own progress. Seven minutes later, 4.20.5 settled failing custom route streams. Two minutes after that, 4.20.6 moved streamContent through the same request-scoped notifier that had just fixed progress.

Progress and streamContent had both been reading from a notifier scoped to the whole server instead of a single request. On a server handling more than one tool call at once, a notification meant for one caller could reach another caller's request instead.

Anyone running fastmcp 4.20.3 or earlier with concurrent tool calls should update to 4.20.6, and should treat any cross-request delivery from that window as something that already happened, not a risk still pending. The release notes don't say how many requests actually crossed before the fix went out.

Catching the progress leak in 4.20.4 but missing the identical pattern in streamContent for two more releases points to a gap in fastmcp's test coverage. Nothing exercises notification scoping under concurrent requests. Until that test exists, the next feature that touches the notifier risks the same bug again.