fix: classify log-delivery failures instead of reporting them as errors#104
Merged
Merged
Conversation
The kit's LoggingService POSTs an INFO log fire-and-forget; on send failure its onError callback re-reported the failure as an UNKNOWN_ERROR / ERROR diagnostic. Client-side network failures (ad-blockers, offline, WebView/CORS restrictions) are common and benign, so this inflated the WSDK error rate with noise that is indistinguishable from genuine SDK errors. Two changes: - ReportingTransport.send now inspects response.ok. fetch only rejects on network failures; an HTTP 5xx resolves with ok === false and was previously swallowed entirely. A non-2xx response now throws an enriched DeliveryError carrying statusCode so callers can tell server-side from client-side failure. - LoggingService.log classifies the failure: network/client failures are reported as a WARNING with the new LOG_DELIVERY_FAILURE code; server-side (5xx) failures stay at ERROR severity so genuine delivery outages remain visible and independently alertable. Tests updated to assert the new code/severity split and to cover the previously-uncaught 5xx path.
crisryantan
approved these changes
Jun 24, 2026
github-actions Bot
pushed a commit
that referenced
this pull request
Jun 25, 2026
## [1.28.2](v1.28.1...v1.28.2) (2026-06-25) ### Bug Fixes * classify log-delivery failures instead of reporting them as errors ([#104](#104)) ([cec8445](cec8445))
Collaborator
|
🎉 This PR is included in version 1.28.2 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
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
3 participants
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
The kit's
LoggingService.log()sends an INFO-level log fire-and-forget. When that POST failed, itsonErrorcallback re-reported the failure as anUNKNOWN_ERROR/ERROR-severity diagnostic.Log-delivery failures are dominated by client-side network conditions — ad-blockers, offline clients, and WebView/CORS restrictions — which are common and benign. Reporting them at
ERRORseverity made them indistinguishable from genuine SDK errors and inflated the observed error rate with noise.This PR reclassifies the signal rather than swallowing it (silently dropping it would also hide genuine server-side delivery failures):
ReportingTransport.sendnow inspectsresponse.ok.fetchonly rejects its promise on network failures; an HTTP 5xx resolves withok === falseand was previously swallowed entirely. A non-2xx response now throws an enrichedDeliveryErrorcarryingstatusCode, so callers can distinguish server-side from client-side failure.LoggingService.logclassifies the failure. Network/client failures are reported as aWARNINGwith a newLOG_DELIVERY_FAILUREcode; server-side (5xx) failures remain atERRORseverity so genuine delivery outages stay visible and independently alertable.codeandseverityare free-form strings serialized into the request body with no downstream branching, so adding the code and changing the severity is not a breaking change.Testing Plan
WARNING/LOG_DELIVERY_FAILUREclassification on a network rejection.ERROR/LOG_DELIVERY_FAILURE.fetchdoes not reject) is now surfaced rather than swallowed.vitest run: 207 passing);eslintclean; bundle builds.dist/is intentionally not included — it is regenerated by CI on merge per repo convention.