Handlers are play-global and deduplicated by name, the last registration
wins, and a notification resolves in the handler's own context rather than
the notifier's. Every app normally re-registers the compose handlers in its
own context through the backend stack right before it notifies, which is what
keeps that resolution correct.
Reconciling entered each client through tasks_from, so the client's core never
ran and no re-registration happened. The last registration in the play then
came from a role imported without vars, which lets the handler-role literal
through, and the guard caught a flush bound to a role that owns no instance
directory. Had the last registration belonged to a real app the guard would
have passed and the restart would have gone to the wrong one, unnoticed.
Rebinding through an include gives the client id as an include parameter,
which outranks the role vars the handler import sets. Flushing inside the loop
keeps a client that does not flush on its own from having its notification
collapsed into the following client's context at the trailing flush.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
kevinveenbirkenbachandClaude Opus 5