You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Batch toolChange notifications for tool registry changes #374
We currently dispatch a toolChange event for every unregistration here and every registration here. This doesn't seem ideal since it's likely that the tool registry is being modified multiple times in one task.
This should likely be done with a JS task finishes to better batch these events.
I'm not strictly opposed, but is there any precedent for this kind of batching besides the microtask that image element mutations queue? /cc @jakearchibald
since it's likely that the tool registry is being modified multiple times in one task.
I think it's common with frameworks. #199 brought up a similar issue, React apps typically tie a tool's lifetime to a component: register in useEffect, abort in cleanup. React runs all of an update's effect cleanups and setups in one synchronous pass, so a single render can unregister and register many tools at once in a single task.
updateTool()/keys from #199 would help when the same component re-renders with new state. But on a route change, components are actually removed and new ones are added, so we'd still fire one event per tool. Batching to one toolchange per task is better to avoid redundant notifications.
I'm not sure about the difference between using a task vs microtask for this. Can you clarify?
We currently mitigate this on the consumer side in webmcpx, maintained by @julianosig: page events are debounced, and refreshes coalesce into one active refresh plus at most one pending refresh. There is a burst test.
This is not the same as batching the platform event per task. It does provide a case for testing: mount several tool-owning components, replace them during a route change, and check that the final catalog is observed without refreshing once per registration. Would that be useful as an implementation fixture?
sorry i didn't follow what you meant by "Would that be useful as an implementation fixture?".
But this data point helps to make a case for better toolChange batching that once per register/unregister. Doing it once per task seems like the most straightforward way but i'm open to other options.
Another related thing came up during the review of #373. If we start batching these notifications, its possible the document toggles to "not fully active" before the toolChange events are dispatched. Like an iframe is detached before the task to dispatch the event runs. we should probably dispatch the suppressed notifications when the document becomes fully active again.
Activity
domfarolino commentedon Nov 4, 2026
I'm not strictly opposed, but is there any precedent for this kind of batching besides the microtask that image element mutations queue? /cc @jakearchibald
Is this true?
khushalsagar commentedon Nov 4, 2026
I think it's common with frameworks. #199 brought up a similar issue, React apps typically tie a tool's lifetime to a component: register in
useEffect, abort in cleanup. React runs all of an update's effect cleanups and setups in one synchronous pass, so a single render can unregister and register many tools at once in a single task.updateTool()/keys from #199 would help when the same component re-renders with new state. But on a route change, components are actually removed and new ones are added, so we'd still fire one event per tool. Batching to onetoolchangeper task is better to avoid redundant notifications.I'm not sure about the difference between using a task vs microtask for this. Can you clarify?
webmcpx commentedon Nov 9, 2026
We currently mitigate this on the consumer side in webmcpx, maintained by @julianosig: page events are debounced, and refreshes coalesce into one active refresh plus at most one pending refresh. There is a burst test.
This is not the same as batching the platform event per task. It does provide a case for testing: mount several tool-owning components, replace them during a route change, and check that the final catalog is observed without refreshing once per registration. Would that be useful as an implementation fixture?
khushalsagar commentedon Nov 9, 2026
sorry i didn't follow what you meant by "Would that be useful as an implementation fixture?".
But this data point helps to make a case for better toolChange batching that once per register/unregister. Doing it once per task seems like the most straightforward way but i'm open to other options.
khushalsagar commentedon Nov 10, 2026
Another related thing came up during the review of #373. If we start batching these notifications, its possible the document toggles to "not fully active" before the toolChange events are dispatched. Like an iframe is detached before the task to dispatch the event runs. we should probably dispatch the suppressed notifications when the document becomes fully active again.
@markafoltz FYI.