fix(logs): harden log schemas against API response format variations#361
Merged
fix(logs): harden log schemas against API response format variations#361
Conversation
Contributor
Semver Impact of This PR🟢 Patch (bug fixes) 📋 Changelog PreviewThis is how your changes will appear in the changelog. Bug Fixes 🐛
Internal Changes 🔧
🤖 This preview updates automatically when you update the PR. |
Contributor
Codecov Results 📊✅ 101 passed | Total: 101 | Pass Rate: 100% | Execution Time: 0ms 📊 Comparison with Base Branch
✨ No test changes detected All tests are passing successfully. ✅ Patch coverage is 82.76%. Project has 3656 uncovered lines. Files with missing lines (2)
Coverage diff@@ Coverage Diff @@
## main #PR +/-##
==========================================
- Coverage 81.51% 81.50% -0.01%
==========================================
Files 128 128 —
Lines 19736 19767 +31
Branches 0 0 —
==========================================
+ Hits 16087 16111 +24
- Misses 3649 3656 +7
- Partials 0 0 —Generated by Codecov Action |
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
BYK
changed the title
- Use z.coerce.number() on timestamp_precise in SentryLogSchema, DetailedSentryLogSchema, and TraceLogSchema to handle APIs returning large nanosecond timestamps as strings (exceeds Number.MAX_SAFE_INTEGER) - Use z.coerce.number() on TraceLogSchema project.id and severity_number for resilience against string-typed numeric fields - Make TraceLogSchema severity_number and timestamp_precise optional since the trace-logs API may omit them - Update LogLike type and follow-mode dedup logic to handle optional timestamp_precise with safe fallbacks - Attach structured Zod validation issues to Sentry context in apiRequestToRegion() for better error diagnostics - Add unit tests for string coercion and missing optional fields - Add property-based tests verifying schema coercion invariants
Logs without timestamp_precise were silently dropped in follow mode because the fallback `?? 0` always evaluates to `0 > lastTs` = false. Use explicit undefined check to always include such logs instead.
…ow mode When timestamp_precise is absent, use a Set of seen log IDs to prevent the same logs from being re-displayed on every poll cycle. Logs with timestamp_precise still use the fast numeric comparison.
- Add onInitialLogs callback to FollowConfig so trace follow mode seeds the seenWithoutTs set from the initial batch, preventing duplicates on the first poll cycle. - Replace Math.random() in property tests with fast-check combinators (oneof, constant, tuple) for deterministic reproducibility.
…irst log When the newest log in a poll batch lacks timestamp_precise, scanning only newLogs[0] fails to advance lastTimestamp, causing logs with timestamp_precise to be re-displayed on subsequent polls. Use a maxTimestamp() helper that finds the highest value across the entire batch for both initial fetch and poll updates.
BYK
force-pushed
the
fix/cli-bh-harden-log-schemas
branch
from
98d364c to
24474d6
Compare
The maxTimestamp() helper scans the entire batch, so the poll's afterTimestamp is the highest value in sampleLogs, not sampleLogs[0].
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
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
1 participant
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.
Fixes CLI-BH
The trace-logs endpoint (
/organizations/{org}/trace-logs/) can return numeric fields as strings or omit optional fields, causing Zod validation failures inapiRequestToRegion().Root Cause
TraceLogSchemaused strictz.number()for fields the API may return as strings or omit:timestamp_precise— nanosecond timestamps (~1.7e18) exceedNumber.MAX_SAFE_INTEGER, so the API may serialize them as stringsproject.id— some responses return numeric IDs as stringsseverity_number— may be absent from certain log entriesChanges
src/types/sentry.ts): Usez.coerce.number()ontimestamp_precise(all 3 log schemas),project.id, andseverity_number. Makeseverity_numberandtimestamp_preciseoptional onTraceLogSchema.src/commands/log/list.ts): Handle optionaltimestamp_precisewith?? lastTimestamp/?? 0in dedup filtering.src/lib/api-client.ts): Attach structured Zod validation issues to Sentry context so future schema failures include field-level details.