From f1c67e7f8d724fc6dd206015b086c7f4ac8eb6f0 Mon Sep 17 00:00:00 2001 From: ImmutableJeffrey Date: Wed, 29 Apr 2026 08:27:55 +1000 Subject: [PATCH] refactor(audience-sdk): drop response-body cap on OnError messages Removes MaxErrorBodyChars (500) and the trim ternary inside ReadBodyForErrorAsync. The cap was defensive against verbose backend responses (stack traces, HTML error pages) but the audience backend returns short structured JSON for both 4xx and 5xx, making the cap dead code. Consumers now see the full response body verbatim. --- .../Audience/Runtime/Transport/HttpTransport.cs | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/src/Packages/Audience/Runtime/Transport/HttpTransport.cs b/src/Packages/Audience/Runtime/Transport/HttpTransport.cs index 96a5a79f..6ec21e3a 100644 --- a/src/Packages/Audience/Runtime/Transport/HttpTransport.cs +++ b/src/Packages/Audience/Runtime/Transport/HttpTransport.cs @@ -282,11 +282,6 @@ private static async Task ParseRejectedCount(HttpResponseMessage response) } } - // Cap the response-body excerpt the caller sees. Backends sometimes - // return verbose stack traces or HTML error pages; trimming keeps - // OnError consumers (loggers, UI) from being flooded. - private const int MaxErrorBodyChars = 500; - // Best-effort body extraction; null on read failure. // Catches narrowed so OOM, OperationCanceledException, and ThreadAbortException // propagate — body extraction must not mask process-level faults. @@ -295,11 +290,7 @@ private static async Task ParseRejectedCount(HttpResponseMessage response) try { var body = await response.Content.ReadAsStringAsync().ConfigureAwait(false); - if (string.IsNullOrWhiteSpace(body)) return null; - body = body.Trim(); - return body.Length > MaxErrorBodyChars - ? body.Substring(0, MaxErrorBodyChars) + "…" - : body; + return string.IsNullOrWhiteSpace(body) ? null : body.Trim(); } catch (HttpRequestException) { return null; } catch (IOException) { return null; }