From 6a06b72cdcd97c3a4ad0e880d50748b057fa8741 Mon Sep 17 00:00:00 2001 From: _Kerman Date: Mon, 19 Oct 2026 15:24:54 +0800 Subject: [PATCH] docs: clarify projection initialization ordering --- .agents/skills/dsh-session-projection/SKILL.md | 1 + 1 file changed, 1 insertion(+) diff --git a/.agents/skills/dsh-session-projection/SKILL.md b/.agents/skills/dsh-session-projection/SKILL.md index 7ebc8714c3..e709e70598 100644 --- a/.agents/skills/dsh-session-projection/SKILL.md +++ b/.agents/skills/dsh-session-projection/SKILL.md @@ -16,3 +16,4 @@ Follow the [projection API](../../../packages/session/session-projection/README. 7. After migrating to Session persistence, stop using `fold` in names and descriptions of the migrated logic. 8. Do not add calls to deprecated synchronous readers (`snapshotEvents`, `eventAt`, `ownEvents`) or wrappers exposing the same access ([decision](../../notes/implemented/architecture/2026-09-09-deprecate-synchronous-session-event-reads.md)). Assume the full event log is not resident in memory and random reads may require asynchronous disk access. 9. Consider state size, replay cost, and per-event work; add complexity only for a concrete performance need. +10. Asynchronous `register()` is usually called in `[Service.init]`. If event listeners are registered afterward, check initialization ordering: when needed, install listeners before awaiting registration; if a listener needs the returned handle, await its readiness in a callback that supports asynchronous waiting. Otherwise, an event may fire before the listener is installed and be missed. Determine whether this race exists from the actual initialization flow and event trigger paths; do not move listeners earlier or add waits mechanically.