Andrew Fribush

fig. 2.18.2: the session-registration race, and the six-line wait that took 0 of 5 runs to 5 of 5

fig. 2.18.2 · the session-registration race, and the six-line wait that took 0 of 5 runs to 5 of 5.
WAITING FOR THE SESSION TO REGISTER TURNS 0 OF 5 RUNS INTO 5 OF 5ONE TIMELINE PER SESSION; ACCENT MARK: LIST_CHANGED, HOLLOW IF UNHEARD.BEFORE THE FIX · 8c87ecaLOAD_MODULES LANDS BEFORE THE SESSION IS REGISTEREDSERVER.SESSIONS IS EMPTY; ADDTOOLS RUNS AT ONCETOOLS/LIST_CHANGED GOES OUTTO 0 SESSIONS; THE SESSION REGISTERS AFTER, UNTOLDCLIENT READS TOOLS/LISTSTILL 7 TOOLS · 0 OF 5 RUNS SAW THE NEW ONESWITH THE WAIT · 413372fLOAD_MODULES LANDS BEFORE THE SESSION IS REGISTEREDSERVER.SESSIONS IS EMPTY; LOAD_MODULES WAITS FOR ITTOOLS/LIST_CHANGED GOES OUTTO 1 SESSION, ONCE THE POLL SEES IT REGISTERCLIENT READS TOOLS/LIST17 TOOLS, ALL CALLABLE · 5 OF 5 RUNS

The wait is six lines in load_modules: poll server.sessions up to 60 times, 25 ms apart, before addTools; worst case 1,500 ms once per session. FastMCP registers a stdio session only after the initialize handshake, so a load_modules call that lands first found no session to notify. The race was reproduced at a 0 ms delay (tools invisible) and absent at 1,500 ms. Counts are the commits’ own verification runs; the 7-to-17 tool list was re-measured over stdio.

source: fedpipe src/server.ts:887-894; commits 8c87eca, 17f9218, 413372f; tools/list re-measured over stdio at 413372f · sessionRace.data.ts

View in context: Lazy tool loading over MCP → · All figures

Andrew Fribush, software and computer engineer in Austin. I build consequential systems where software meets institutions: finance, healthcare, commerce, government data, and the mechanisms that govern AI agents. Taking new engagements: hello@andrewfribush.com.