Tracked from upstream issue benjitaylor#138.
Type: bug • Severity: low
Assessment
The described race is not reproducible in the fork's current single-process code: events.ts:60 does ++globalSequence and sqlite.ts:317 runs the synchronous better-sqlite3 INSERT with no await between them, so Node's single-threaded loop serializes each emit+persist atomically and concurrent MCP calls cannot collide on sequence. The reporter's microtask-interleave theory does not hold for this synchronous path; the only real residual risk is two server processes sharing ~/.agentation/store.db (each with its own in-memory counter restored from MAX(sequence)), an uncommon setup. No open PR addresses the sequence logic. A defensive hardening (switch the events.sequence column to AUTOINCREMENT or add a retry-on-constraint loop) is small but fixes a non-manifesting bug, so it is worth tracking rather than shipping now.
Upstream: benjitaylor#138
Tracked from upstream issue benjitaylor#138.
Type: bug • Severity: low
Assessment
The described race is not reproducible in the fork's current single-process code: events.ts:60 does ++globalSequence and sqlite.ts:317 runs the synchronous better-sqlite3 INSERT with no await between them, so Node's single-threaded loop serializes each emit+persist atomically and concurrent MCP calls cannot collide on sequence. The reporter's microtask-interleave theory does not hold for this synchronous path; the only real residual risk is two server processes sharing ~/.agentation/store.db (each with its own in-memory counter restored from MAX(sequence)), an uncommon setup. No open PR addresses the sequence logic. A defensive hardening (switch the events.sequence column to AUTOINCREMENT or add a retry-on-constraint loop) is small but fixes a non-manifesting bug, so it is worth tracking rather than shipping now.
Upstream: benjitaylor#138