fix(review): tighten the regate-repair attempt cap to 2 and surface it to Sentry - #3760
Conversation
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3760 +/- ##
=======================================
Coverage 93.29% 93.29%
=======================================
Files 317 317
Lines 32368 32369 +1
Branches 11872 11872
=======================================
+ Hits 30199 30200 +1
Misses 1537 1537
Partials 632 632
🚀 New features to boost your workflow:
|
|
Caution 🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥 🛑 Gittensory review result - fixes requiredReview updated: 2026-07-06 07:54:35 UTC
🛑 Suggested Action - Manual Review
Review summary Nits — 5 non-blocking
Why this is blocked
CI checks failing
Review context
Contributor next steps
Signal definitions
🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.
|
32eca1f to
6db5f7e
Compare
…t to Sentry Lower REGATE_REPAIR_MAX_ATTEMPTS_PER_SHA from 3 to 2 (#3747 follow-up) -- one fewer wasted attempt per stuck SHA before the sweep falls back to ordinary staleness-gated cadence. Also add a matching structured console.error at the moment a SHA exhausts its repair budget, so it flows through the existing forwardStructuredLogToSentry pipeline instead of being visible only via a direct audit_events query (level:"error" is deliberate -- the line's own existence IS the anomaly signal, same convention as selfhost_ai_provider_ failed / selfhost_ai_providers_exhausted).
6db5f7e to
00535b9
Compare
Summary
REGATE_REPAIR_MAX_ATTEMPTS_PER_SHAfrom 3 to 2 -- one fewer wasted repair attempt per stuck head SHA before the sweep falls back to ordinary staleness-gated cadence.console.errorat the moment a SHA exhausts its repair budget, so the event flows through the existingforwardStructuredLogToSentrypipeline. Previously this was a DB-onlyaudit_eventswrite with no operator visibility until someone queries the ledger directly (which is how today's incident was found) -- now it surfaces as a Sentry issue automatically, tagged by repo/pullNumber per the existingSENTRY_LOG_TAG_KEYSconvention.Scope
type(scope): short summaryConventional Commit format.CONTRIBUTING.mdand does not reintroduce GitHub Pages, VitePress,site/, orCNAME.Validation
git diff --checknpm run actionlint-- not run (no workflow files touched)npm run typecheck-- cleannpm run test:coverage(full/unsharded) -- not run locally; ran the full affected file directly instead (test/unit/queue.test.ts, 588/588 passed, including updated regression assertions for both changes)npm run test:workers/npm run build:mcp/npm run test:mcp-pack/npm run ui:openapi:check/npm run ui:lint/npm run ui:typecheck/npm run ui:build/npm audit --audit-level=moderate-- not run locally (no wrangler/MCP/UI/dependency surface touched); left to CI.Safety