fix(observability): surface RAG index-population failures to Sentry - #1625
Merged
Conversation
fetchRepoTree and listStoredChunkPaths logged their catch failures via console.log with no level, so the central Sentry forwarder (level:error/fatal only) never saw them — a broken RAG index population (GitHub tree fetch down, D1 read error) silently degraded retrieval quality with no signal. Promote both to level:error (event rag_index_tree_error / rag_list_paths_error, keeping the ev tag for log continuity), mirroring the rag.ts pattern from #1619. Both stay fail-safe; only visibility changes. Covered by the existing tree-throws and stored-paths-read-error tests, now asserting the level:error log.
Contributor
|
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 #1625 +/- ##
=======================================
Coverage 95.51% 95.51%
=======================================
Files 204 204
Lines 22051 22051
Branches 7966 7966
=======================================
Hits 21062 21062
Misses 413 413
Partials 576 576
🚀 New features to boost your workflow:
|
8 tasks
JSONbored
added a commit
that referenced
this pull request
Jun 28, 2026
…the event slug (#1636) forwardStructuredLogToSentry titled each issue with only obj.event and buried the real failure in a 'log' context blob — so operators had to open each issue to learn what broke. Now: - title leads with the failure: "<event>: <message ?? error>" (e.g. orb_broker_unavailable: The operation was aborted due to timeout) - index filterable tags for the dimensions operators search/group by (repo, installationId, pull, pr, project, kind, deliveryId), present values only - fingerprint by event so recurrences collapse into one issue instead of fragmenting on the variable detail now in the title Pairs with the source-side instrumentation (#1605/#1619/#1625/#1627/#1628): those make failures reach Sentry; this makes each issue legible at a glance.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Extends the review-pipeline Sentry coverage (after #1619 covered RAG retrieval / enrichment / inline failures) to the RAG index-population path.
fetchRepoTreeandlistStoredChunkPaths(rag-index.ts) logged their catch failures viaconsole.logwith nolevel, so the central Sentry forwarder (which forwards onlylevel:"error"/"fatal") never saw them — a broken index population (GitHub tree fetch down, D1 read error) silently degraded RAG quality with no Sentry signal.Promote both to
level:"error"event:"rag_index_tree_error"/"rag_list_paths_error"(keeping theevtag for log continuity), mirroring the #1619 rag.ts pattern. Both remain fail-safe (population still degrades gracefully) — only visibility changes.Extends #1618. (The two outer-catch population sites —
rag_index_repo_error/rag_reindex_paths_error— are defensive/unreachable in the current tests and are a separate follow-up with their own coverage.)Scope
site//CNAME/Pages; followsCONTRIBUTING.md.Validation
git diff --check·actionlint·typechecktest:coverage— both promoted catches are exercised by the existing rag-index tests (tree-throws; stored-paths read error), now asserting thelevel:"error"log; no new branches.test:workers·build:mcp·test:mcp-pack·ui:*·npm audit --audit-level=moderateIf any required check was skipped, explain why:
Safety
Notes