Observed friction
Launching six independent opencode run --model openai/gpt-5.6-terra jobs in dedicated worktrees caused first-message memory composition timeouts before model work. Two captured startup logs reported:
[dm-agent-sync] memory compose timed out after 10003ms; using existing memory files
[dm-agent-sync] memory compose timed out after 10004ms; using existing memory files
This adds avoidable startup latency and falls back to existing context during a normal parallel repair workflow. The observed timeout alone does not prove contention was its cause; composition timing and selected transport need diagnosis.
Source evidence
bridges/kimaki/plugins/dm-agent-sync.ts maintains synchronizedSessions inside one plugin instance, keyed by session ID. Each new session invokes a separate wp datamachine memory compose; this map does not coalesce equivalent requests across sessions or CLI processes targeting the same site/agent. Every first message awaits its own request for up to ten seconds.
Desired contract
- Equivalent concurrent refresh requests share an owning-layer freshness/refresh operation keyed by actual site, agent and relevant context identity.
- Freshness and failure receipts distinguish reused context, successful refresh and stale fallback, with bounded timing and actionable diagnostics.
- Refresh invalidation preserves context correctness when memory inputs change.
- A concurrent multi-process test proves bounded startup work rather than merely increasing the timeout or disabling refresh.
Inspect whether Data Machine already owns an appropriate reusable primitive before introducing bridge-local coordination. Related Data Machine #3409 concerns orphan process cleanup after timeout; this issue concerns redundant fanout refresh and context freshness admission.
AI assistance
GPT-6 Astra through OpenCode observed the direct-run startup warnings, inspected the session-local synchronization code, checked existing trackers, and drafted this issue under Chris Huber's direction.
Observed friction
Launching six independent
opencode run --model openai/gpt-5.6-terrajobs in dedicated worktrees caused first-message memory composition timeouts before model work. Two captured startup logs reported:This adds avoidable startup latency and falls back to existing context during a normal parallel repair workflow. The observed timeout alone does not prove contention was its cause; composition timing and selected transport need diagnosis.
Source evidence
bridges/kimaki/plugins/dm-agent-sync.tsmaintainssynchronizedSessionsinside one plugin instance, keyed by session ID. Each new session invokes a separatewp datamachine memory compose; this map does not coalesce equivalent requests across sessions or CLI processes targeting the same site/agent. Every first message awaits its own request for up to ten seconds.Desired contract
Inspect whether Data Machine already owns an appropriate reusable primitive before introducing bridge-local coordination. Related Data Machine #3409 concerns orphan process cleanup after timeout; this issue concerns redundant fanout refresh and context freshness admission.
AI assistance
GPT-6 Astra through OpenCode observed the direct-run startup warnings, inspected the session-local synchronization code, checked existing trackers, and drafted this issue under Chris Huber's direction.