test: qualify shared OpenCode SQLite across containers

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

dries/ocman#382

dries commented

2026-07-18 00:17:32 +02:00

Owner

Superseded

#384 rejects shared or bind-mounted OpenCode SQLite for container mode. This qualification work is no longer on the delivery path; retain this issue as historical rationale only.

Parent

#375

What to build

Prove or disprove the compatibility-first assumption that several managed OpenCode containers plus ocman can safely and acceptably share one host-visible OpenCode data directory and WAL database. Produce a repeatable qualification harness, measured results, supported-runtime guidance, and runtime diagnostics for failure modes.

This ticket must not declare shared SQLite safe based only on SQLite WAL theory or current native multi-process behavior. It must exercise the actual supported container/filesystem combinations, including Docker Desktop where applicable.

Acceptance criteria

A repeatable test launches several project containers that concurrently create sessions, stream messages, write parts, and are read by ocman.
The matrix covers the documented container engine/filesystem environments, including native Linux and Docker Desktop where they are claimed as supported.
Tests cover graceful restart, abrupt process/container kill, engine restart, ocman restart, concurrent startup/migration, and host suspend/resume where practical.
Results record lock/busy errors, latency, throughput, WAL/SHM growth, checkpoint behavior, database size growth, and recovery time.
Integrity and visibility are verified after each failure scenario without mutating or relying on a developer's real OpenCode database.
UID/GID and bind-mount permission failures produce actionable diagnostics.
Version skew and database migration policy for multiple containers is documented and enforced or rejected.
A clear support decision is recorded for each tested environment: supported, experimental with limits, or unsupported.
Safe concurrency/resource recommendations and backup/recovery instructions are documented.
If the shared database fails qualification, container mode remains experimental/disabled by default and #384 records the required alternative.

Blocked by

#378
#379

## Superseded #384 rejects shared or bind-mounted OpenCode SQLite for container mode. This qualification work is no longer on the delivery path; retain this issue as historical rationale only. ## Parent #375 ## What to build Prove or disprove the compatibility-first assumption that several managed OpenCode containers plus ocman can safely and acceptably share one host-visible OpenCode data directory and WAL database. Produce a repeatable qualification harness, measured results, supported-runtime guidance, and runtime diagnostics for failure modes. This ticket must not declare shared SQLite safe based only on SQLite WAL theory or current native multi-process behavior. It must exercise the actual supported container/filesystem combinations, including Docker Desktop where applicable. ## Acceptance criteria - [ ] A repeatable test launches several project containers that concurrently create sessions, stream messages, write parts, and are read by ocman. - [ ] The matrix covers the documented container engine/filesystem environments, including native Linux and Docker Desktop where they are claimed as supported. - [ ] Tests cover graceful restart, abrupt process/container kill, engine restart, ocman restart, concurrent startup/migration, and host suspend/resume where practical. - [ ] Results record lock/busy errors, latency, throughput, WAL/SHM growth, checkpoint behavior, database size growth, and recovery time. - [ ] Integrity and visibility are verified after each failure scenario without mutating or relying on a developer's real OpenCode database. - [ ] UID/GID and bind-mount permission failures produce actionable diagnostics. - [ ] Version skew and database migration policy for multiple containers is documented and enforced or rejected. - [ ] A clear support decision is recorded for each tested environment: supported, experimental with limits, or unsupported. - [ ] Safe concurrency/resource recommendations and backup/recovery instructions are documented. - [ ] If the shared database fails qualification, container mode remains experimental/disabled by default and #384 records the required alternative. ## Blocked by - #378 - #379

dries added the

labels

dries referenced this issue

2026-07-18 00:17:46 +02:00

feat: ship container runtime settings, diagnostics, and lifecycle UX #383

2026-07-18 00:18:00 +02:00

design: decide long-term OpenCode data isolation #384

2026-07-18 00:18:34 +02:00

epic: optionally run managed OpenCode instances in containers #375

2026-07-20 13:56:53 +02:00

dries closed this issue

2026-07-20 13:57:42 +02:00