Capture startup failures before the frontend recorder attaches
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 50/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
- Domain
- cli, testing-qa
Research direction
Start with the startup path around ServerConnection.resolve, Tui.run, and Drive.create(), then reproduce the failure using the isolated CLI/server processes and timing gate described in the issue. Compare the baseline and repaired PTY recordings. Done means an early exit before the frontend recorder attaches still retains an exportable stdout/stderr or PTY recording.
Written by the indexing model from the issue text.
Description
Could Drive retain a terminal recording when OpenCode exits before its frontend control endpoint starts?
While verifying managed-service bootstrap against OpenCode V2 68b28bdb98, the CLI successfully resolves server A, then A exits before Tui.run makes its first request. The current code fails with ClientError: Transport before reaching Drive.create(). A repaired build renders successfully, but the baseline has no frontend recorder to capture its failure. Drive 2.1.3's scripted --server path also bypasses the managed resolution boundary this test needs.
The reproduction uses isolated real CLI/server processes and a timing gate after actual ServerConnection.resolve: stop owned A, start B at another address, then release the TUI. We captured matched before/after PTY recordings with Terminal Control. A pre-attachment stdout/stderr or PTY capture, retained and exportable on early exit, would let Drive cover this startup failure without waiting for a renderer that never starts.
- Dominant language
- TypeScript
- Stars
- 32
- Forks
- 4
- Avg merge
- 10m
- Merged PRs (30d)
- 13
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from anomalyco/opencode-drive
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
anomalyco/opencode-drive#102 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 58/100
anomalyco/opencode-drive#104 · 1 comment ·
Maintainers usually reply within 1 day
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 55/100
anomalyco/opencode-drive#97 ·
Maintainers usually reply within 1 day
-
documentation
Difficulty 3/5 1-2 days Newbie friendliness 68/100
anomalyco/opencode-drive#86 · 1 comment ·
Maintainers usually reply within 1 day
-
documentation
Difficulty 4/5 3-5 days Newbie friendliness 52/100
anomalyco/opencode-drive#85 ·
Maintainers usually reply within 1 day
All issues in anomalyco/opencode-drive
Similar issues
-
Mend: dependency security vulnerability untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
opensearch-project/security-dashboards-plugin#2545 ·
Maintainers usually reply within 1 day
-
Add: Dream TR SDOpencheck:passed streams:add
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
doctor integrity sample scans soft-deleted pages on Postgres (batch path has no deleted_at filter)Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
SocialGouv/egapro#4672 · 1 comment ·
Maintainers usually reply within 2 days
-
area:agents area:tui bug
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
anthropics/claude-code#98358 ·
Maintainers usually reply within 1 day