Compaction: Concurrency/locking robustness and retries

[riatzukiza]

Epic: #46

Summary

Harden compaction concurrency/locking and retry behavior to avoid race conditions and partial writes.

Problem

• Concurrent compactions or aborts can cause partial state or confusing outcomes.

Proposal

• Validate locking coverage: session lock acquired for all compactions without external signal.
• Handle abort race gracefully; ensure summary text part is either complete or clearly aborted with usable content.
• Retry backoff already exists; verify edge cases and add tests.

Code Refs

• packages/opencode/src/session/compaction.ts:90-93 (SessionLock usage)
• packages/opencode/src/session/compaction.ts:262-313 (retry loop)

Tasks

• Add tests simulating concurrent compactions and aborts
• Ensure final message/parts are consistent after abort
• Improve error metadata/logs for aborted retries

Acceptance Criteria

• No data corruption or confusing partial state under concurrent/aborted compactions.

[riatzukiza]

Related Issues & Context

This Concurrency and Locking robustness issue is foundational to ALL other compaction work:

Critical Dependencies:

• Compaction: Smarter boundary selection and cross-session guard #47 - Boundary Selection: Boundary decisions must be atomic and consistent under concurrent access
• Compaction: Preserve rules/constraints across compaction #48 - Rules Preservation: Rules can't be lost due to race conditions during compaction
• Compaction: Structured BUILD-mode handoff summary prompt #49 - Structured Handoff: Handoff generation must complete cleanly or abort cleanly - no partial states
• Compaction: Pruning/soft compaction and selective tool-output deletion #50 - Pruning: Pruning operations must be safe when concurrent with other session operations

Safety Critical:

• Compaction: Provider options flow and accurate usage accounting #51 - Usage Accounting: Concurrent operations must not corrupt usage tracking
• Compaction: Telemetry and /status for context + decisions #52 - Telemetry: Logging must be thread-safe and provide accurate concurrency information

Strategic Importance:

• Epic: Subagent State Handoff & Context Boundary Resilience #56 - Subagent State Handoff: Concurrency patterns established here become the foundation for:
  • Parent-child session communication safety
  • Subagent cancellation and abort handling
  • Race condition prevention in state handoff

Technical Infrastructure:

The locking and abort patterns developed here serve as templates for:

• Subagent session lifecycle management
• Context boundary crossing safety
• Error propagation across concurrent operations

Implementation Priority:

Concurrency safety should be implemented EARLY because:

1. Foundation: All other compaction features depend on safe concurrency
2. Risk Mitigation: Race conditions can cause data corruption and lost state
3. Test Coverage: Need concurrency tests before adding more complex features

Cross-Cutting Impact:

This issue establishes the safety guarantees for BOTH:

1. Compaction operations - safe context transfer within sessions over time
2. Subagent communication - safe context transfer between agents concurrently

Without proper concurrency safety, both compaction and subagent features risk:

• Silent data corruption
• Lost rules and constraints
• Inconsistent state propagation
• Unrecoverable error conditions

The abort handling patterns are especially important for the "stuck subagent" problem mentioned in the Subagent State Handoff epic.