feat(providers): add context compaction across harnesses by maria-rcks · Pull Request #8808 · pingdotgg/t3code

No issues identified (5 code objects reviewed).

• Reviewed files modified since 7edb7f6; other PR files not modified since then were skipped.
• Merge Base: 535c83d
• Head: f5b7a12

✅	File Path	U3 Bytes	Comments Posted	Reason
✅	`apps/server/src/provider/Layers/OpenCodeAdapter.ts`	674	0
➖	`apps/server/src/provider/Layers/OpenCodeAdapter.test.ts`	1276		Excluded by default ignore patterns
➖	`apps/server/src/provider/Layers/ProviderService.test.ts`	97		Excluded by default ignore patterns
➖	`apps/server/src/orchestration/Layers/ProviderCommandReactor.test.ts`	253		Excluded by default ignore patterns
✅	`apps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts`	261	0
✅	`apps/server/src/provider/Layers/ProviderService.ts`	405	0
✅	`apps/server/src/orchestration/Layers/ProviderCommandReactor.ts`	1194	0

Billed Total: 10.00KB of diff | $0.50 (This review was charged at our per-review byte minimum of 10.00KB. Learn more here)

apps/server/src/orchestration/Layers/ProviderCommandReactor.ts

line 1284: Successful native /compact requests leave the pending turn-start placeholder behind. thread.turn.start always creates that placeholder, but this branch calls compactThread directly; Codex/OpenCode native compaction completes through thread.state.changed, which the runtime ingestion handles only as a context-compaction activity and never deletes the pending row. Only failure activities (or normal turn lifecycle events) clear it, so the compact command remains displayed/treated as a pending turn until a later request replaces it. [ Already posted ]

apps/server/src/provider/Layers/OpenCodeAdapter.ts

line 3027: compactThread registers as a native compaction with ProviderService before it waits for promptSemaphore. If an already-started turn finishes during that wait, its ordinary turn.completed event settles the service's pending-compaction deferred as completed. Once the permit is acquired and session.summarize succeeds, the caller immediately returns using that stale completion, before the actual compaction event arrives; the orchestration layer can then admit another turn while compaction is still running. [ Already posted ]

apps/server/src/provider/Layers/ProviderService.ts

line 919: compactThread records only a pending entry per threadId and then settles it from the next turn.completed event, without retaining or comparing the turnId returned by the fallback sendTurn. Thus a delayed completion from a prior/unrelated turn on that thread can be consumed as the compaction result: a successful unrelated completion emits the synthesized compacted event and returns success while the actual /compact command is still running (and its later terminal event is ignored). Correlate the pending operation to the fallback turn id before settling it. [ Already posted ]