A failed `prepare` destroys its own diagnostic evidence
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 0
- Forks
- 0
- Avg merge
- 1h 58m
- Merged PRs (30d)
- 48
Description
supabase prepare failed and pointed me at a log. The log's payload was:
supabase_analytics_faretable-newgit-trial container logs:
supabase_vector_faretable-newgit-trial container logs:
Stopping containers...
supabase_analytics_faretable-newgit-trial container is not ready: unhealthy
Two empty container logs: sections, then teardown. newgit captured the hook's stdout faithfully — but the child command destroyed the evidence before exiting, so the capture is worthless. I abandoned newgit, ran supabase start by hand outside the tool, and diagnosed it there.
This is largely the child tool's fault. But newgit is the thing holding the log and the thing I asked for an answer, so it is where the gap is felt.
Possible directions, in rough order of cost:
- Document the pattern: when a long-running
preparefails, reproduce vianewgit run <instance> -- <command>before digging into the log. - Keep the resolved-command header prominent —
[newgit] $ pg_dump ...at the top of the log is what made #87's bug obvious once I looked. - A
--keep-failed, if there is any generic way to express "don't let the hook clean up after itself."
Separately: that log was 95,941 lines for one prepare, and newgit action prints all of it to stdout as well as to the log. A --quiet that logs in full but summarises on the terminal would be welcome.
Environment: newgit 0.3.0 (fba8fa7090e2), macOS 15 (Darwin 25.6.0), APFS. npm-workspaces monorepo (Expo/React Native + Next.js + Supabase); local stack is Supabase CLI 2.107.0 (12 containers, Docker Desktop 28.2.2), Metro, and a Dockerised routing service. 4 instances spawned over one session; resources deps (install), expo (process), supabase (command-snapshot-migrations), r5 (project-owned).
Contributor guide
No contributing guide indexed for this repository
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.
Research direction
Start by reproducing the failed prepare flow and compare newgit run <instance> -- <command> with the captured log from newgit action. Clarify whether the goal is preserving failed-command diagnostics, adding --quiet, or documenting recovery; done should include a clear reproduction and a defined diagnostic outcome.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, rust
- Domain
- cli, observability
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100