fix(ops): stop tracked live metrics surface from silently reporting a zero pipeline - #73
fix(ops): stop tracked live metrics surface from silently reporting a zero pipeline#73nish3451 wants to merge 5 commits into
Conversation
…peline Running growth:metrics in a checkout with no private outbound prospect state exited 0 with 'created' and overwrote the git-tracked live-metrics.md with an all-zero pipeline (0 prospects) while the canonical service root holds 50 prospect folders. Eight other operator surfaces also invoke the metrics exporter as a nested child with the tracked default output, so running any of them from a state-less or mixed-root invocation could clobber the tracked surface the same way. - Refuse (exit 1, loud stderr, no writes) when the target is the tracked default live metrics file and the service root holds no outbound prospect pipeline state. State means at least one real prospect folder with pipeline.json, so an empty prospects/ directory refuses too. Explicit --output= under runs/ keeps generating zero-state private reports, now with a stderr warning when the prospect root is absent. - Point the eight nested metrics calls (benchmark, cockpit, dashboard, parity, doctor, learning review, money mission, proof run) at a private runs/live-metrics.md output: they only consume the JSON counts, so the tracked surface is no longer refreshed as their side effect from arbitrary working directories. - Restore the tracked live metrics to the real pipeline regeneration: 50 prospects, 43 active, 5 scored, 12 scored including inactive, and 3 blocked client records.
… state The byte-identical operator-surface gate regenerated live-metrics.md from a hermetic empty prospect root, which is exactly the state-less path that clobbered the tracked surface with zeros in production. - Assert the exporter refuses (exit 1, no write) when regenerating the tracked default output from a root without prospect pipeline state. - Reproduce the tracked pipeline in the fixture root (38 new, 5 scored, 7 paused = 50 prospects with 12 scored including inactive, 3 unregistered client folders) so the guarded tracked surface still regenerates byte-identically through the real path. - Drop the fixture before the remaining assertions, and regenerate the tracked surface explicitly before reading it mid-test now that nested surfaces no longer refresh it as a side effect.
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
|
Warning Review limit reached
Next review available in: 23 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (11)
Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fa9ddc51dc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const resolvedOutputPath = isAbsolute(outputPath) ? outputPath : join(repoRoot, outputPath); | ||
| const prospectRoot = join(repoRoot, "prospects"); | ||
| const trackedMetricsPath = join(repoRoot, "growth-brain/ops/live-metrics.md"); |
There was a problem hiding this comment.
Write the report through the resolved service-root path
When this script is invoked directly from a lane/code checkout with SERVICE_REPO_ROOT pointing to the canonical service root, resolvedOutputPath is used only to decide whether the guard applies; the final mkdirSync and writeFileSync still use outputPath, which is resolved against process.cwd(). The guard can therefore validate the canonical pipeline and exit successfully while overwriting the lane checkout's tracked metrics and leaving the canonical service-root report stale. Use the resolved path for directory creation and writing.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3d9545b426
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| runJson(["scripts/export-sales-cockpit.mjs"]); | ||
| runJson(["scripts/export-daily-money-mission.mjs", "--limit=5"]); | ||
| const metrics = runJson(["scripts/export-growth-metrics.mjs"]); | ||
| const metrics = runJson(["scripts/export-growth-metrics.mjs", "--output=runs/live-metrics.md"]); |
There was a problem hiding this comment.
Link the cockpit to the newly generated metrics report
When npm run growth:cockpit is run after the pipeline changes, this child call now refreshes runs/live-metrics.md, but the generated cockpit still links its “Live Metrics” button to ../growth-brain/ops/live-metrics.md (line 207). Because this change deliberately stops nested calls from refreshing that tracked file, the button presents the commit-time snapshot while the cockpit itself uses current counts; update the link and reported links entry to target the private report generated here.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
Why
The tracked operator metrics surface (growth-brain/ops/live-metrics.md) reported a zero pipeline (0 prospects) while the canonical service root holds 50 prospect folders. The tracked file was silently clobbered by any regeneration run from a checkout with no private outbound prospect state — the same state-less clobber bug class fixed for the 11/10 proof-run brief, still present for live metrics.
Two mechanisms caused it:
What changed
Verification
Note for reviewers
The pending fix/proof-run-brief-zero-pipeline-lane1 branch also edits scripts/export-market-proof-run.mjs around the metrics call; if one merges before the other, that line needs a trivial merge resolution (keep both changes).