[sentry-junior]

Reader side for background compaction. Nothing writes these events yet.

Ship order: this must go out in a release before any PR that writes compaction_requested or compaction_prepared. Older code decodes unknown types as unknown, and projection throws on them, so every turn would fail for a conversation that has one of these rows. The schemas are strict, so a later field addition by the writer also needs a reader release first.

Events (appendable, schema version 1):

• compaction_requested: markSeq (last event seq the summary covers), historyVersion, modelProfile, modelId.
• compaction_prepared: the same fields plus outcome. ready requires summary; failed requires errorType (a fixed label, max 64 chars, no exception text).

Readers:

• Pi projection skips both explicitly. A summary enters model context only through the compaction event that swaps it in.
• Forks do not copy them. A copied request would look like a pending job that never runs for the fork.
• Reporting already uses an allowlist of source types, so the dashboard does not show them. The search tool returns them like other events, behind the existing payload visibility check.

replaceHistory takes an optional expectedHistoryVersion. It is checked under the conversation event lock. On mismatch it writes nothing and returns { status: "conflict", historyVersion: current }. Otherwise it returns { status: "replaced", historyVersion: new }. Existing callers pass nothing and keep current behavior.

Open question: should the dashboard show prepared/failed background compactions? This PR leaves them out of reporting.

via @thomasjiangcy.

--

View Session [Sentry]

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
junior-docs	Ready	Preview	Nov 3, 2026 11:20am UTC

[github-actions]

1 screenshot change — 1 changed · 0 added · 0 removed

Review screenshots in Frameshift

Settings Mcp · Desktop Changed