registrystack / registrystack/registry-stack
caseworkctl doctor reports a generic failure without naming the failed check
- Dominant language
- Rust
- Stars
- 2
- Forks
- 0
- Avg merge
- 2h 55m
- Merged PRs (30d)
- 130
Description
Found while writing the public tutorial `Review BReg changes in Casework`.
## What Happened
`caseworkctl doctor` against a runtime whose dependency checks failed answered, in JSON as well as in the human-readable output:
```
caseworkctl.operational-failure
A Casework runtime dependency check failed.
```
with no field saying which check failed (database reachability, migration state, issuer, source binding). The sentence comes from the fallback arm in `crates/registry-caseworkctl/src/lib.rs` where no project or semantic error is attached.
## Expected Behavior
`doctor` reports each check it ran with its own outcome and, for a failed check, the component and the reason, without leaking connection strings or secret values. #990 asks for the same thing on the source binding path at runtime startup; this issue covers the `doctor` command.
## Environment
Registry Stack 0.30.0 release binaries, macOS.
Triage: later.
Contributor guide
Research direction
Start in crates/registry-caseworkctl/src/lib.rs, at the fallback arm used by caseworkctl doctor when no project or semantic error is attached. Run doctor against a runtime with failed dependency checks and compare its JSON and human-readable output. Done means each check reports its outcome, failed checks name the component and reason, and connection strings or secrets remain hidden.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 72/100