fix(server): replay all un-applied events during projection bootstrap

[krutftw]

What Changed

apps/server/src/orchestration/Layers/ProjectionPipeline.ts, bootstrapProjector: pass Number.MAX_SAFE_INTEGER as the limit to eventStore.readFromSequence(lastAppliedSequence, …) so projection catch-up on startup replays every un-applied event instead of the default first 1 000. One argument plus a three-line comment; no other behaviour change. The store still reads in READ_PAGE_SIZE (500) pages, so memory stays bounded — this is exactly how the store's own readAll() is defined.

Why

Fixes#7537. readFromSequence's limit defaults to DEFAULT_READ_FROM_SEQUENCE_LIMIT = 1_000, and bootstrap did not pass one. If more than 1 000 events are un-applied at startup (events appended while the server was down — offline t3 project CLI writes, external writers, repeated crash-before-project), only the first 1 000 are projected, projection_state advances to last_applied + 1000, and the next live event's runProjectorForEvent upserts last_applied_sequence to the new max — so the gap is never replayed and those projects/threads/messages are permanently missing from the projections (and from invariants such as requireActiveProjectWorkspaceRootAbsent).

Verified by reading the shipped bundle (0.0.34-nightly.20260819.1132) and main. No existing test encodes the cap (OrchestrationEngine.test.ts stubs readFromSequence: () => Stream.empty, which accepts any arguments); I did not add a new test for the >1 000 case because I could not run the suite from this environment — happy to add one if you want it.

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

---

Authorship disclosure: investigated and prepared by Claude (Fable 5) running in Claude Code on the author's machine, at the author's request.

---

Note

Medium Risk
Changes orchestration projection bootstrap replay semantics and can increase startup work when large backlogs exist, but scope is limited to catch-up reads and aligns with readAll behavior.

Overview
Fixes projection bootstrap silently stopping after 1,000 un-applied events when readFromSequence used its default limit. bootstrapProjector now passes Number.MAX_SAFE_INTEGER as the read limit so startup catch-up replays the full backlog; paging still uses the event store’s page size, so memory stays bounded.

Adds an integration test that appends 1,001 events behind a lagging projects projector and asserts projection_state advances to the latest sequence after bootstrap.

^{Reviewed by Cursor Bugbot for commit e84a70e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix projection bootstrap to replay backlog beyond event store default limit

Passes Number.MAX_SAFE_INTEGER as the explicit limit to eventStore.readFromSequence inside the bootstrapProjector helper in ProjectionPipeline.ts, so bootstrap processes the full backlog instead of stopping at the event store's default page size. Adds a test in ProjectionPipeline.test.ts that appends 1,001 project.created events and confirms the projects projector catches up to the last sequence. Risk: reading with no practical limit could load a very large event stream into memory during bootstrap for projectors far behind the head sequence.

📊 Macroscope summarized e84a70e. 1 file reviewed, 1 issue evaluated, 1 issue filtered, 0 comments posted

🗂️ Filtered Issues

apps/server/src/orchestration/Layers/ProjectionPipeline.ts — 0 comments posted, 1 evaluated, 1 filtered

• line 1730: bootstrapProjector passes an effectively unbounded limit to a paginated query with no high-water-mark snapshot. readFromSequence issues another WHERE sequence > cursor LIMIT 500 query whenever a page is nonempty, so an external writer that keeps appending enough events to keep pages nonempty makes the stream never terminate. Since engine construction awaits projectionPipeline.bootstrap before starting its command worker, this can indefinitely prevent server startup; capture the maximum sequence before replay (or otherwise bound the replay) instead of following a moving tail. [ Already posted ]

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e62b12a9-7e5d-464c-b70f-81600247bab6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — Projection bootstrap now replays an effectively unbounded event stream before the orchestration server starts, rather than stopping at 1,000 events. Paging limits memory, but concurrent appends could prolong startup indefinitely, so the runtime availability impact should receive human review.

^{You can add or adjust custom eligibility rules. Learn more.}

Dismissing prior approval to re-evaluate c777f44

[macroscopeapp]

Effect service conventions: the service definition, imports, layer, and error modeling in this change are consistent with the conventions. One change-discipline gap: this is a backend behavior change to projection bootstrap with no accompanying focused test.

^{Posted via Macroscope — Effect Service Conventions}

Dismissing prior approval to re-evaluate e84a70e

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Approved. makeOrchestrationEngine waits for projectionPipeline.bootstrap before it starts the command worker, so the supported server cannot append during bootstrap. The event store still reads 500 rows per page.

[krutftw]

What Changed

apps/server/src/orchestration/Layers/ProjectionPipeline.ts, bootstrapProjector: pass Number.MAX_SAFE_INTEGER as the limit to eventStore.readFromSequence(lastAppliedSequence, …) so projection catch-up on startup replays every un-applied event instead of the default first 1 000. One argument plus a three-line comment; no other behaviour change. The store still reads in READ_PAGE_SIZE (500) pages, so memory stays bounded — this is exactly how the store's own readAll() is defined.

Why

Fixes#7537. readFromSequence's limit defaults to DEFAULT_READ_FROM_SEQUENCE_LIMIT = 1_000, and bootstrap did not pass one. If more than 1 000 events are un-applied at startup (events appended while the server was down — offline t3 project CLI writes, external writers, repeated crash-before-project), only the first 1 000 are projected, projection_state advances to last_applied + 1000, and the next live event's runProjectorForEvent upserts last_applied_sequence to the new max — so the gap is never replayed and those projects/threads/messages are permanently missing from the projections (and from invariants such as requireActiveProjectWorkspaceRootAbsent).

Verified by reading the shipped bundle (0.0.34-nightly.20260819.1132) and main. No existing test encodes the cap (OrchestrationEngine.test.ts stubs readFromSequence: () => Stream.empty, which accepts any arguments); I did not add a new test for the >1 000 case because I could not run the suite from this environment — happy to add one if you want it.

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

---

Authorship disclosure: investigated and prepared by Claude (Fable 5) running in Claude Code on the author's machine, at the author's request.

---

Note

Medium Risk
Changes orchestration projection bootstrap replay semantics and can increase startup work when large backlogs exist, but scope is limited to catch-up reads and aligns with readAll behavior.

Overview
Fixes projection bootstrap silently stopping after 1,000 un-applied events when readFromSequence used its default limit. bootstrapProjector now passes Number.MAX_SAFE_INTEGER as the read limit so startup catch-up replays the full backlog; paging still uses the event store’s page size, so memory stays bounded.

Adds an integration test that appends 1,001 events behind a lagging projects projector and asserts projection_state advances to the latest sequence after bootstrap.

^{Reviewed by Cursor Bugbot for commit e84a70e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix projection bootstrap to replay backlog beyond event store default limit

Passes Number.MAX_SAFE_INTEGER as the explicit limit to eventStore.readFromSequence inside the bootstrapProjector helper in ProjectionPipeline.ts, so bootstrap processes the full backlog instead of stopping at the event store's default page size. Adds a test in ProjectionPipeline.test.ts that appends 1,001 project.created events and confirms the projects projector catches up to the last sequence. Risk: reading with no practical limit could load a very large event stream into memory during bootstrap for projectors far behind the head sequence.

📊 Macroscope summarized e84a70e. 1 file reviewed, 1 issue evaluated, 1 issue filtered, 0 comments posted

🗂️ Filtered Issues

apps/server/src/orchestration/Layers/ProjectionPipeline.ts — 0 comments posted, 1 evaluated, 1 filtered

• line 1730: bootstrapProjector passes an effectively unbounded limit to a paginated query with no high-water-mark snapshot. readFromSequence issues another WHERE sequence > cursor LIMIT 500 query whenever a page is nonempty, so an external writer that keeps appending enough events to keep pages nonempty makes the stream never terminate. Since engine construction awaits projectionPipeline.bootstrap before starting its command worker, this can indefinitely prevent server startup; capture the maximum sequence before replay (or otherwise bound the replay) instead of following a moving tail. [ Already posted ]

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e62b12a9-7e5d-464c-b70f-81600247bab6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — Projection bootstrap now replays an effectively unbounded event stream before the orchestration server starts, rather than stopping at 1,000 events. Paging limits memory, but concurrent appends could prolong startup indefinitely, so the runtime availability impact should receive human review.

^{You can add or adjust custom eligibility rules. Learn more.}

Dismissing prior approval to re-evaluate c777f44

[macroscopeapp]

Effect service conventions: the service definition, imports, layer, and error modeling in this change are consistent with the conventions. One change-discipline gap: this is a backend behavior change to projection bootstrap with no accompanying focused test.

^{Posted via Macroscope — Effect Service Conventions}

Dismissing prior approval to re-evaluate e84a70e

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Approved. makeOrchestrationEngine waits for projectionPipeline.bootstrap before it starts the command worker, so the supported server cannot append during bootstrap. The event store still reads 500 rows per page.

[krutftw]

What Changed

apps/server/src/orchestration/Layers/ProjectionPipeline.ts, bootstrapProjector: pass Number.MAX_SAFE_INTEGER as the limit to eventStore.readFromSequence(lastAppliedSequence, …) so projection catch-up on startup replays every un-applied event instead of the default first 1 000. One argument plus a three-line comment; no other behaviour change. The store still reads in READ_PAGE_SIZE (500) pages, so memory stays bounded — this is exactly how the store's own readAll() is defined.

Why

Fixes#7537. readFromSequence's limit defaults to DEFAULT_READ_FROM_SEQUENCE_LIMIT = 1_000, and bootstrap did not pass one. If more than 1 000 events are un-applied at startup (events appended while the server was down — offline t3 project CLI writes, external writers, repeated crash-before-project), only the first 1 000 are projected, projection_state advances to last_applied + 1000, and the next live event's runProjectorForEvent upserts last_applied_sequence to the new max — so the gap is never replayed and those projects/threads/messages are permanently missing from the projections (and from invariants such as requireActiveProjectWorkspaceRootAbsent).

Verified by reading the shipped bundle (0.0.34-nightly.20260819.1132) and main. No existing test encodes the cap (OrchestrationEngine.test.ts stubs readFromSequence: () => Stream.empty, which accepts any arguments); I did not add a new test for the >1 000 case because I could not run the suite from this environment — happy to add one if you want it.

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

---

Authorship disclosure: investigated and prepared by Claude (Fable 5) running in Claude Code on the author's machine, at the author's request.

---

Note

Medium Risk
Changes orchestration projection bootstrap replay semantics and can increase startup work when large backlogs exist, but scope is limited to catch-up reads and aligns with readAll behavior.

Overview
Fixes projection bootstrap silently stopping after 1,000 un-applied events when readFromSequence used its default limit. bootstrapProjector now passes Number.MAX_SAFE_INTEGER as the read limit so startup catch-up replays the full backlog; paging still uses the event store’s page size, so memory stays bounded.

Adds an integration test that appends 1,001 events behind a lagging projects projector and asserts projection_state advances to the latest sequence after bootstrap.

^{Reviewed by Cursor Bugbot for commit e84a70e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix projection bootstrap to replay backlog beyond event store default limit

Passes Number.MAX_SAFE_INTEGER as the explicit limit to eventStore.readFromSequence inside the bootstrapProjector helper in ProjectionPipeline.ts, so bootstrap processes the full backlog instead of stopping at the event store's default page size. Adds a test in ProjectionPipeline.test.ts that appends 1,001 project.created events and confirms the projects projector catches up to the last sequence. Risk: reading with no practical limit could load a very large event stream into memory during bootstrap for projectors far behind the head sequence.

📊 Macroscope summarized e84a70e. 1 file reviewed, 1 issue evaluated, 1 issue filtered, 0 comments posted

🗂️ Filtered Issues

apps/server/src/orchestration/Layers/ProjectionPipeline.ts — 0 comments posted, 1 evaluated, 1 filtered

• line 1730: bootstrapProjector passes an effectively unbounded limit to a paginated query with no high-water-mark snapshot. readFromSequence issues another WHERE sequence > cursor LIMIT 500 query whenever a page is nonempty, so an external writer that keeps appending enough events to keep pages nonempty makes the stream never terminate. Since engine construction awaits projectionPipeline.bootstrap before starting its command worker, this can indefinitely prevent server startup; capture the maximum sequence before replay (or otherwise bound the replay) instead of following a moving tail. [ Already posted ]

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e62b12a9-7e5d-464c-b70f-81600247bab6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — Projection bootstrap now replays an effectively unbounded event stream before the orchestration server starts, rather than stopping at 1,000 events. Paging limits memory, but concurrent appends could prolong startup indefinitely, so the runtime availability impact should receive human review.

^{You can add or adjust custom eligibility rules. Learn more.}

Dismissing prior approval to re-evaluate c777f44

[macroscopeapp]

Effect service conventions: the service definition, imports, layer, and error modeling in this change are consistent with the conventions. One change-discipline gap: this is a backend behavior change to projection bootstrap with no accompanying focused test.

^{Posted via Macroscope — Effect Service Conventions}

Dismissing prior approval to re-evaluate e84a70e

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Approved. makeOrchestrationEngine waits for projectionPipeline.bootstrap before it starts the command worker, so the supported server cannot append during bootstrap. The event store still reads 500 rows per page.

[krutftw]

What Changed

apps/server/src/orchestration/Layers/ProjectionPipeline.ts, bootstrapProjector: pass Number.MAX_SAFE_INTEGER as the limit to eventStore.readFromSequence(lastAppliedSequence, …) so projection catch-up on startup replays every un-applied event instead of the default first 1 000. One argument plus a three-line comment; no other behaviour change. The store still reads in READ_PAGE_SIZE (500) pages, so memory stays bounded — this is exactly how the store's own readAll() is defined.

Why

Fixes#7537. readFromSequence's limit defaults to DEFAULT_READ_FROM_SEQUENCE_LIMIT = 1_000, and bootstrap did not pass one. If more than 1 000 events are un-applied at startup (events appended while the server was down — offline t3 project CLI writes, external writers, repeated crash-before-project), only the first 1 000 are projected, projection_state advances to last_applied + 1000, and the next live event's runProjectorForEvent upserts last_applied_sequence to the new max — so the gap is never replayed and those projects/threads/messages are permanently missing from the projections (and from invariants such as requireActiveProjectWorkspaceRootAbsent).

Verified by reading the shipped bundle (0.0.34-nightly.20260819.1132) and main. No existing test encodes the cap (OrchestrationEngine.test.ts stubs readFromSequence: () => Stream.empty, which accepts any arguments); I did not add a new test for the >1 000 case because I could not run the suite from this environment — happy to add one if you want it.

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

---

Authorship disclosure: investigated and prepared by Claude (Fable 5) running in Claude Code on the author's machine, at the author's request.

---

Note

Medium Risk
Changes orchestration projection bootstrap replay semantics and can increase startup work when large backlogs exist, but scope is limited to catch-up reads and aligns with readAll behavior.

Overview
Fixes projection bootstrap silently stopping after 1,000 un-applied events when readFromSequence used its default limit. bootstrapProjector now passes Number.MAX_SAFE_INTEGER as the read limit so startup catch-up replays the full backlog; paging still uses the event store’s page size, so memory stays bounded.

Adds an integration test that appends 1,001 events behind a lagging projects projector and asserts projection_state advances to the latest sequence after bootstrap.

^{Reviewed by Cursor Bugbot for commit e84a70e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix projection bootstrap to replay backlog beyond event store default limit

Passes Number.MAX_SAFE_INTEGER as the explicit limit to eventStore.readFromSequence inside the bootstrapProjector helper in ProjectionPipeline.ts, so bootstrap processes the full backlog instead of stopping at the event store's default page size. Adds a test in ProjectionPipeline.test.ts that appends 1,001 project.created events and confirms the projects projector catches up to the last sequence. Risk: reading with no practical limit could load a very large event stream into memory during bootstrap for projectors far behind the head sequence.

📊 Macroscope summarized e84a70e. 1 file reviewed, 1 issue evaluated, 1 issue filtered, 0 comments posted

🗂️ Filtered Issues

apps/server/src/orchestration/Layers/ProjectionPipeline.ts — 0 comments posted, 1 evaluated, 1 filtered

• line 1730: bootstrapProjector passes an effectively unbounded limit to a paginated query with no high-water-mark snapshot. readFromSequence issues another WHERE sequence > cursor LIMIT 500 query whenever a page is nonempty, so an external writer that keeps appending enough events to keep pages nonempty makes the stream never terminate. Since engine construction awaits projectionPipeline.bootstrap before starting its command worker, this can indefinitely prevent server startup; capture the maximum sequence before replay (or otherwise bound the replay) instead of following a moving tail. [ Already posted ]

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e62b12a9-7e5d-464c-b70f-81600247bab6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — Projection bootstrap now replays an effectively unbounded event stream before the orchestration server starts, rather than stopping at 1,000 events. Paging limits memory, but concurrent appends could prolong startup indefinitely, so the runtime availability impact should receive human review.

^{You can add or adjust custom eligibility rules. Learn more.}

Dismissing prior approval to re-evaluate c777f44

[macroscopeapp]

Effect service conventions: the service definition, imports, layer, and error modeling in this change are consistent with the conventions. One change-discipline gap: this is a backend behavior change to projection bootstrap with no accompanying focused test.

^{Posted via Macroscope — Effect Service Conventions}

Dismissing prior approval to re-evaluate e84a70e

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Approved. makeOrchestrationEngine waits for projectionPipeline.bootstrap before it starts the command worker, so the supported server cannot append during bootstrap. The event store still reads 500 rows per page.

[krutftw]

What Changed

apps/server/src/orchestration/Layers/ProjectionPipeline.ts, bootstrapProjector: pass Number.MAX_SAFE_INTEGER as the limit to eventStore.readFromSequence(lastAppliedSequence, …) so projection catch-up on startup replays every un-applied event instead of the default first 1 000. One argument plus a three-line comment; no other behaviour change. The store still reads in READ_PAGE_SIZE (500) pages, so memory stays bounded — this is exactly how the store's own readAll() is defined.

Why

Fixes#7537. readFromSequence's limit defaults to DEFAULT_READ_FROM_SEQUENCE_LIMIT = 1_000, and bootstrap did not pass one. If more than 1 000 events are un-applied at startup (events appended while the server was down — offline t3 project CLI writes, external writers, repeated crash-before-project), only the first 1 000 are projected, projection_state advances to last_applied + 1000, and the next live event's runProjectorForEvent upserts last_applied_sequence to the new max — so the gap is never replayed and those projects/threads/messages are permanently missing from the projections (and from invariants such as requireActiveProjectWorkspaceRootAbsent).

Verified by reading the shipped bundle (0.0.34-nightly.20260819.1132) and main. No existing test encodes the cap (OrchestrationEngine.test.ts stubs readFromSequence: () => Stream.empty, which accepts any arguments); I did not add a new test for the >1 000 case because I could not run the suite from this environment — happy to add one if you want it.

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

---

Authorship disclosure: investigated and prepared by Claude (Fable 5) running in Claude Code on the author's machine, at the author's request.

---

Note

Medium Risk
Changes orchestration projection bootstrap replay semantics and can increase startup work when large backlogs exist, but scope is limited to catch-up reads and aligns with readAll behavior.

Overview
Fixes projection bootstrap silently stopping after 1,000 un-applied events when readFromSequence used its default limit. bootstrapProjector now passes Number.MAX_SAFE_INTEGER as the read limit so startup catch-up replays the full backlog; paging still uses the event store’s page size, so memory stays bounded.

Adds an integration test that appends 1,001 events behind a lagging projects projector and asserts projection_state advances to the latest sequence after bootstrap.

^{Reviewed by Cursor Bugbot for commit e84a70e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix projection bootstrap to replay backlog beyond event store default limit

Passes Number.MAX_SAFE_INTEGER as the explicit limit to eventStore.readFromSequence inside the bootstrapProjector helper in ProjectionPipeline.ts, so bootstrap processes the full backlog instead of stopping at the event store's default page size. Adds a test in ProjectionPipeline.test.ts that appends 1,001 project.created events and confirms the projects projector catches up to the last sequence. Risk: reading with no practical limit could load a very large event stream into memory during bootstrap for projectors far behind the head sequence.

📊 Macroscope summarized e84a70e. 1 file reviewed, 1 issue evaluated, 1 issue filtered, 0 comments posted

🗂️ Filtered Issues

apps/server/src/orchestration/Layers/ProjectionPipeline.ts — 0 comments posted, 1 evaluated, 1 filtered

• line 1730: bootstrapProjector passes an effectively unbounded limit to a paginated query with no high-water-mark snapshot. readFromSequence issues another WHERE sequence > cursor LIMIT 500 query whenever a page is nonempty, so an external writer that keeps appending enough events to keep pages nonempty makes the stream never terminate. Since engine construction awaits projectionPipeline.bootstrap before starting its command worker, this can indefinitely prevent server startup; capture the maximum sequence before replay (or otherwise bound the replay) instead of following a moving tail. [ Already posted ]

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e62b12a9-7e5d-464c-b70f-81600247bab6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — Projection bootstrap now replays an effectively unbounded event stream before the orchestration server starts, rather than stopping at 1,000 events. Paging limits memory, but concurrent appends could prolong startup indefinitely, so the runtime availability impact should receive human review.

^{You can add or adjust custom eligibility rules. Learn more.}

Dismissing prior approval to re-evaluate c777f44

[macroscopeapp]

Effect service conventions: the service definition, imports, layer, and error modeling in this change are consistent with the conventions. One change-discipline gap: this is a backend behavior change to projection bootstrap with no accompanying focused test.

^{Posted via Macroscope — Effect Service Conventions}

Dismissing prior approval to re-evaluate e84a70e

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Approved. makeOrchestrationEngine waits for projectionPipeline.bootstrap before it starts the command worker, so the supported server cannot append during bootstrap. The event store still reads 500 rows per page.

[krutftw]

What Changed

apps/server/src/orchestration/Layers/ProjectionPipeline.ts, bootstrapProjector: pass Number.MAX_SAFE_INTEGER as the limit to eventStore.readFromSequence(lastAppliedSequence, …) so projection catch-up on startup replays every un-applied event instead of the default first 1 000. One argument plus a three-line comment; no other behaviour change. The store still reads in READ_PAGE_SIZE (500) pages, so memory stays bounded — this is exactly how the store's own readAll() is defined.

Why

Fixes#7537. readFromSequence's limit defaults to DEFAULT_READ_FROM_SEQUENCE_LIMIT = 1_000, and bootstrap did not pass one. If more than 1 000 events are un-applied at startup (events appended while the server was down — offline t3 project CLI writes, external writers, repeated crash-before-project), only the first 1 000 are projected, projection_state advances to last_applied + 1000, and the next live event's runProjectorForEvent upserts last_applied_sequence to the new max — so the gap is never replayed and those projects/threads/messages are permanently missing from the projections (and from invariants such as requireActiveProjectWorkspaceRootAbsent).

Verified by reading the shipped bundle (0.0.34-nightly.20260819.1132) and main. No existing test encodes the cap (OrchestrationEngine.test.ts stubs readFromSequence: () => Stream.empty, which accepts any arguments); I did not add a new test for the >1 000 case because I could not run the suite from this environment — happy to add one if you want it.

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

---

Authorship disclosure: investigated and prepared by Claude (Fable 5) running in Claude Code on the author's machine, at the author's request.

---

Note

Medium Risk
Changes orchestration projection bootstrap replay semantics and can increase startup work when large backlogs exist, but scope is limited to catch-up reads and aligns with readAll behavior.

Overview
Fixes projection bootstrap silently stopping after 1,000 un-applied events when readFromSequence used its default limit. bootstrapProjector now passes Number.MAX_SAFE_INTEGER as the read limit so startup catch-up replays the full backlog; paging still uses the event store’s page size, so memory stays bounded.

Adds an integration test that appends 1,001 events behind a lagging projects projector and asserts projection_state advances to the latest sequence after bootstrap.

^{Reviewed by Cursor Bugbot for commit e84a70e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix projection bootstrap to replay backlog beyond event store default limit

Passes Number.MAX_SAFE_INTEGER as the explicit limit to eventStore.readFromSequence inside the bootstrapProjector helper in ProjectionPipeline.ts, so bootstrap processes the full backlog instead of stopping at the event store's default page size. Adds a test in ProjectionPipeline.test.ts that appends 1,001 project.created events and confirms the projects projector catches up to the last sequence. Risk: reading with no practical limit could load a very large event stream into memory during bootstrap for projectors far behind the head sequence.

📊 Macroscope summarized e84a70e. 1 file reviewed, 1 issue evaluated, 1 issue filtered, 0 comments posted

🗂️ Filtered Issues

apps/server/src/orchestration/Layers/ProjectionPipeline.ts — 0 comments posted, 1 evaluated, 1 filtered

• line 1730: bootstrapProjector passes an effectively unbounded limit to a paginated query with no high-water-mark snapshot. readFromSequence issues another WHERE sequence > cursor LIMIT 500 query whenever a page is nonempty, so an external writer that keeps appending enough events to keep pages nonempty makes the stream never terminate. Since engine construction awaits projectionPipeline.bootstrap before starting its command worker, this can indefinitely prevent server startup; capture the maximum sequence before replay (or otherwise bound the replay) instead of following a moving tail. [ Already posted ]

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e62b12a9-7e5d-464c-b70f-81600247bab6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — Projection bootstrap now replays an effectively unbounded event stream before the orchestration server starts, rather than stopping at 1,000 events. Paging limits memory, but concurrent appends could prolong startup indefinitely, so the runtime availability impact should receive human review.

^{You can add or adjust custom eligibility rules. Learn more.}

Dismissing prior approval to re-evaluate c777f44

[macroscopeapp]

Effect service conventions: the service definition, imports, layer, and error modeling in this change are consistent with the conventions. One change-discipline gap: this is a backend behavior change to projection bootstrap with no accompanying focused test.

^{Posted via Macroscope — Effect Service Conventions}

Dismissing prior approval to re-evaluate e84a70e

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Approved. makeOrchestrationEngine waits for projectionPipeline.bootstrap before it starts the command worker, so the supported server cannot append during bootstrap. The event store still reads 500 rows per page.

[krutftw]

What Changed

apps/server/src/orchestration/Layers/ProjectionPipeline.ts, bootstrapProjector: pass Number.MAX_SAFE_INTEGER as the limit to eventStore.readFromSequence(lastAppliedSequence, …) so projection catch-up on startup replays every un-applied event instead of the default first 1 000. One argument plus a three-line comment; no other behaviour change. The store still reads in READ_PAGE_SIZE (500) pages, so memory stays bounded — this is exactly how the store's own readAll() is defined.

Why

Fixes#7537. readFromSequence's limit defaults to DEFAULT_READ_FROM_SEQUENCE_LIMIT = 1_000, and bootstrap did not pass one. If more than 1 000 events are un-applied at startup (events appended while the server was down — offline t3 project CLI writes, external writers, repeated crash-before-project), only the first 1 000 are projected, projection_state advances to last_applied + 1000, and the next live event's runProjectorForEvent upserts last_applied_sequence to the new max — so the gap is never replayed and those projects/threads/messages are permanently missing from the projections (and from invariants such as requireActiveProjectWorkspaceRootAbsent).

Verified by reading the shipped bundle (0.0.34-nightly.20260819.1132) and main. No existing test encodes the cap (OrchestrationEngine.test.ts stubs readFromSequence: () => Stream.empty, which accepts any arguments); I did not add a new test for the >1 000 case because I could not run the suite from this environment — happy to add one if you want it.

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

---

Authorship disclosure: investigated and prepared by Claude (Fable 5) running in Claude Code on the author's machine, at the author's request.

---

Note

Medium Risk
Changes orchestration projection bootstrap replay semantics and can increase startup work when large backlogs exist, but scope is limited to catch-up reads and aligns with readAll behavior.

Overview
Fixes projection bootstrap silently stopping after 1,000 un-applied events when readFromSequence used its default limit. bootstrapProjector now passes Number.MAX_SAFE_INTEGER as the read limit so startup catch-up replays the full backlog; paging still uses the event store’s page size, so memory stays bounded.

Adds an integration test that appends 1,001 events behind a lagging projects projector and asserts projection_state advances to the latest sequence after bootstrap.

^{Reviewed by Cursor Bugbot for commit e84a70e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix projection bootstrap to replay backlog beyond event store default limit

Passes Number.MAX_SAFE_INTEGER as the explicit limit to eventStore.readFromSequence inside the bootstrapProjector helper in ProjectionPipeline.ts, so bootstrap processes the full backlog instead of stopping at the event store's default page size. Adds a test in ProjectionPipeline.test.ts that appends 1,001 project.created events and confirms the projects projector catches up to the last sequence. Risk: reading with no practical limit could load a very large event stream into memory during bootstrap for projectors far behind the head sequence.

📊 Macroscope summarized e84a70e. 1 file reviewed, 1 issue evaluated, 1 issue filtered, 0 comments posted

🗂️ Filtered Issues

apps/server/src/orchestration/Layers/ProjectionPipeline.ts — 0 comments posted, 1 evaluated, 1 filtered

• line 1730: bootstrapProjector passes an effectively unbounded limit to a paginated query with no high-water-mark snapshot. readFromSequence issues another WHERE sequence > cursor LIMIT 500 query whenever a page is nonempty, so an external writer that keeps appending enough events to keep pages nonempty makes the stream never terminate. Since engine construction awaits projectionPipeline.bootstrap before starting its command worker, this can indefinitely prevent server startup; capture the maximum sequence before replay (or otherwise bound the replay) instead of following a moving tail. [ Already posted ]

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e62b12a9-7e5d-464c-b70f-81600247bab6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — Projection bootstrap now replays an effectively unbounded event stream before the orchestration server starts, rather than stopping at 1,000 events. Paging limits memory, but concurrent appends could prolong startup indefinitely, so the runtime availability impact should receive human review.

^{You can add or adjust custom eligibility rules. Learn more.}

Dismissing prior approval to re-evaluate c777f44

[macroscopeapp]

Effect service conventions: the service definition, imports, layer, and error modeling in this change are consistent with the conventions. One change-discipline gap: this is a backend behavior change to projection bootstrap with no accompanying focused test.

^{Posted via Macroscope — Effect Service Conventions}

Dismissing prior approval to re-evaluate e84a70e

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Approved. makeOrchestrationEngine waits for projectionPipeline.bootstrap before it starts the command worker, so the supported server cannot append during bootstrap. The event store still reads 500 rows per page.

[krutftw]

What Changed

apps/server/src/orchestration/Layers/ProjectionPipeline.ts, bootstrapProjector: pass Number.MAX_SAFE_INTEGER as the limit to eventStore.readFromSequence(lastAppliedSequence, …) so projection catch-up on startup replays every un-applied event instead of the default first 1 000. One argument plus a three-line comment; no other behaviour change. The store still reads in READ_PAGE_SIZE (500) pages, so memory stays bounded — this is exactly how the store's own readAll() is defined.

Why

Fixes#7537. readFromSequence's limit defaults to DEFAULT_READ_FROM_SEQUENCE_LIMIT = 1_000, and bootstrap did not pass one. If more than 1 000 events are un-applied at startup (events appended while the server was down — offline t3 project CLI writes, external writers, repeated crash-before-project), only the first 1 000 are projected, projection_state advances to last_applied + 1000, and the next live event's runProjectorForEvent upserts last_applied_sequence to the new max — so the gap is never replayed and those projects/threads/messages are permanently missing from the projections (and from invariants such as requireActiveProjectWorkspaceRootAbsent).

Verified by reading the shipped bundle (0.0.34-nightly.20260819.1132) and main. No existing test encodes the cap (OrchestrationEngine.test.ts stubs readFromSequence: () => Stream.empty, which accepts any arguments); I did not add a new test for the >1 000 case because I could not run the suite from this environment — happy to add one if you want it.

UI Changes

None.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

---

Authorship disclosure: investigated and prepared by Claude (Fable 5) running in Claude Code on the author's machine, at the author's request.

---

Note

Medium Risk
Changes orchestration projection bootstrap replay semantics and can increase startup work when large backlogs exist, but scope is limited to catch-up reads and aligns with readAll behavior.

Overview
Fixes projection bootstrap silently stopping after 1,000 un-applied events when readFromSequence used its default limit. bootstrapProjector now passes Number.MAX_SAFE_INTEGER as the read limit so startup catch-up replays the full backlog; paging still uses the event store’s page size, so memory stays bounded.

Adds an integration test that appends 1,001 events behind a lagging projects projector and asserts projection_state advances to the latest sequence after bootstrap.

^{Reviewed by Cursor Bugbot for commit e84a70e. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix projection bootstrap to replay backlog beyond event store default limit

Passes Number.MAX_SAFE_INTEGER as the explicit limit to eventStore.readFromSequence inside the bootstrapProjector helper in ProjectionPipeline.ts, so bootstrap processes the full backlog instead of stopping at the event store's default page size. Adds a test in ProjectionPipeline.test.ts that appends 1,001 project.created events and confirms the projects projector catches up to the last sequence. Risk: reading with no practical limit could load a very large event stream into memory during bootstrap for projectors far behind the head sequence.

📊 Macroscope summarized e84a70e. 1 file reviewed, 1 issue evaluated, 1 issue filtered, 0 comments posted

🗂️ Filtered Issues

apps/server/src/orchestration/Layers/ProjectionPipeline.ts — 0 comments posted, 1 evaluated, 1 filtered

• line 1730: bootstrapProjector passes an effectively unbounded limit to a paginated query with no high-water-mark snapshot. readFromSequence issues another WHERE sequence > cursor LIMIT 500 query whenever a page is nonempty, so an external writer that keeps appending enough events to keep pages nonempty makes the stream never terminate. Since engine construction awaits projectionPipeline.bootstrap before starting its command worker, this can indefinitely prevent server startup; capture the maximum sequence before replay (or otherwise bound the replay) instead of following a moving tail. [ Already posted ]

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e62b12a9-7e5d-464c-b70f-81600247bab6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — Projection bootstrap now replays an effectively unbounded event stream before the orchestration server starts, rather than stopping at 1,000 events. Paging limits memory, but concurrent appends could prolong startup indefinitely, so the runtime availability impact should receive human review.

^{You can add or adjust custom eligibility rules. Learn more.}

Dismissing prior approval to re-evaluate c777f44

[macroscopeapp]

Effect service conventions: the service definition, imports, layer, and error modeling in this change are consistent with the conventions. One change-discipline gap: this is a backend behavior change to projection bootstrap with no accompanying focused test.

^{Posted via Macroscope — Effect Service Conventions}

Dismissing prior approval to re-evaluate e84a70e

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Approved. makeOrchestrationEngine waits for projectionPipeline.bootstrap before it starts the command worker, so the supported server cannot append during bootstrap. The event store still reads 500 rows per page.