feat(audience): surface server-side validation rejection reasons#822
Merged
Conversation
nattb8
marked this pull request as ready for review
July 22, 2026 03:26
nattb8
force-pushed
the
feat/sdk-684-surface-server-validation-rejections
branch
from
July 22, 2026 03:46
a4b1a30 to
60356a3
Compare
Audience SDK — Build Size
SDK Size = build minus empty app. Change = vs baseline. Fails if any platform exceeds its absolute size limit. |
…er message Matches the TS SDK's console.error decision: a rejection the studio didn't catch client-side is lost data, not an advisory, so it should log louder than Warn. Debug/Warn share one delegate wired to plain Debug.Log with severity conveyed only by a text prefix, so a new ErrorWriter delegate wires Log.Error to a real Debug.LogError instead, giving it genuine Editor/crash- reporting severity while keeping the existing capture-based test pattern. Also aggregates the per-flush log to one call instead of one per rejected message, since a batch can carry many rejections and that many separate Debug.LogError calls would flood the console. Additionally: the 2xx path only surfaced rejection detail when the body's numeric rejected count was greater than 0, while the 4xx path always did regardless of any count. rejected and rejections are parsed independently from the same body, so a body where they've drifted apart would silently drop detail on the success path; both paths now fall back to rejections.Count when rejected is 0. Also fixed a stale helper name/message (ParseRejectedCountThrew) left over from an earlier rename of ParseRejectedCount to ParseRejectedResult. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
nattb8
force-pushed
the
feat/sdk-684-surface-server-validation-rejections
branch
from
July 22, 2026 05:22
60356a3 to
ff8d093
Compare
JCSanPedro
approved these changes
Jul 22, 2026
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
Ticket: SDK-684
Client-side validation (SDK-679) mirrors the server's rules, but the two will drift over time; today a rejection the server catches and the client doesn't is discarded silently once a flush completes. This adds a default, non-opt-in log per rejected message, and enriches the existing
onErrorAudienceErrorwith a typedRejectionslist so integrators already usingonErrorget structured data instead of hand-parsing the response. Covers both the 2xx-with-rejections and the 4xx-rejected response shapes, since the backend uses the same body for both.This is lost data, not an advisory, so it logs at
Log.Error(realDebug.LogError, not just a Warn-level text prefix) rather thanLog.Warn. It's also aggregated into one call per flush instead of one per rejected message, since a batch can carry many rejections and separateDebug.LogErrorcalls would flood the console.HttpTransportonly countedrejected; per-message detail was discardedLog.Errorper flush listing every rejected messageId + field + reason, independent ofonErroronErrorAudienceErrorhad no way to carry per-message detail at allRejections: IReadOnlyList<MessageRejection>?, parsed from the same responserejectedcount was > 0rejections.Counttoo, so a body where the two have drifted apart doesn't silently drop detail (4xx already didn't have this gap)Test plan
dotnet buildanddotnet testpass: 389 passed, 1 skipped (pre-existing), 0 faileddotnet format --verify-no-changescleanRejectionspopulated on 2xx and 4xx, one aggregatedLog.Errorcall fires with noonErrorwired,Log.ErrorusesErrorWriter(notWriter) and fires regardless ofLog.Enabled, malformedrejectionsin the body leaves itnullinstead of throwing, a 2xx body withrejected: 0but a non-emptyrejectionsarray still firesonError🤖 Generated with Claude Code