capture response body for failed requests and if tracing is enabled in SentryHttpClient

[martinhaintz]

📜 Description

If sendDefaultPii is enabled and maxResponseBodySize is bigger than the responseBodySize, the body is logged in sentry.

💡 Motivation and Context

close #2220

💚 How did you test it?

📝 Checklist

• I reviewed submitted code
• I added tests to verify changes
• No new PII added or SDK only sends newly added PII if sendDefaultPii is enabled
• I updated the docs if needed
• All tests passing
• No breaking changes

🔮 Next steps

[github-actions]

	Fails
🚫	Please consider adding a changelog entry for the next release.

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Instructions and example for changelog

Please add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number.

Example:

## Unreleased

- capture response body for failed requests and if tracing is enabled in SentryHttpClient ([#2293](https://github.com/getsentry/sentry-dart/pull/2293))

If none of the above apply, you can opt out of this check by adding #skip-changelog to the PR description.

Generated by 🚫 dangerJS against da865b2

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.93%. Comparing base (16063b2) to head (da865b2).
Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2293      +/-   ##
==========================================
- Coverage   88.35%   86.93%   -1.42%     
==========================================
  Files         247      104     -143     
  Lines        8578     3713    -4865     
==========================================
- Hits         7579     3228    -4351     
+ Misses        999      485     -514     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

iOS Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	1231.69 ms	1256.85 ms	25.16 ms
Size	8.38 MiB	9.73 MiB	1.36 MiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
d8f5abb	1237.73 ms	1259.13 ms	21.39 ms
f275487	1291.65 ms	1339.92 ms	48.26 ms
fcd1ee4	1247.18 ms	1251.35 ms	4.16 ms
f7f46dc	1285.82 ms	1315.06 ms	29.24 ms
ba9c106	1241.76 ms	1265.15 ms	23.40 ms
77db8d4	1228.47 ms	1248.80 ms	20.33 ms
ccc09e4	1254.74 ms	1277.08 ms	22.34 ms
dd933d4	1238.73 ms	1252.43 ms	13.70 ms
d883d62	1221.39 ms	1230.18 ms	8.80 ms
6034b0a	1244.89 ms	1270.22 ms	25.33 ms

App size

Revision	Plain	With Sentry	Diff
d8f5abb	8.33 MiB	9.40 MiB	1.07 MiB
f275487	8.32 MiB	9.38 MiB	1.05 MiB
fcd1ee4	8.29 MiB	9.36 MiB	1.07 MiB
f7f46dc	8.10 MiB	9.17 MiB	1.08 MiB
ba9c106	8.32 MiB	9.38 MiB	1.06 MiB
77db8d4	8.38 MiB	9.73 MiB	1.35 MiB
ccc09e4	8.16 MiB	9.16 MiB	1.01 MiB
dd933d4	8.33 MiB	9.64 MiB	1.31 MiB
d883d62	8.29 MiB	9.36 MiB	1.07 MiB
6034b0a	8.33 MiB	9.40 MiB	1.07 MiB

[buenaflor]

let's rethink this, I don't think deprecating this flag is the right way to go

[kahest]

we still want to provide this flag to disable capturing of failed network requests completely, so yes we shouldn't deprecate this

[buenaflor]

@kahest JS Replay uses captureNetworkBodies for both request and response

getsentry/sentry-javascript#7589

wdyt if we also adopt this flag?

[kahest]

@kahest JS Replay uses captureNetworkBodies for both request and response

getsentry/sentry-javascript#7589

wdyt if we also adopt this flag?

I think this has since been dropped in favor of networkDetailAllowUrls - see docs. I also don't see references to the option in code anymore.

I like the new option - it makes it more granular and explicit, though of course it's more work. It's still only available for JS SR I think, so not widely adopted. If there's no competing option for other HTTP integrations on other SDKs, I'm fine with adopting this

[buenaflor]

Ah I missed that, thx. I'll have a look at it

[buenaflor]

@kahest I haven't found anything specific in other SDKs that allow sending http response bodies other than replay.

However it's possible a user can do this:

beforeSend: (event, hint) async {
    final response = hint.get(TypeCheckHint.httpResponse);
    if (response is StreamedResponse) {
        final body = getResponseBody(response)
        // user can now use it
    }
}

this also aligns with what the js http integration would like to add: getsentry/sentry-javascript#12544

[kahest]

@buenaflor IIUC this would work for http+dio? I like the idea, it's very flexible and allows users to decide based on endpoint etc. if they want to add, but of course it's more complex to use than a switch

[buenaflor]

this would work for http+dio

yes but only errors so this won't work for transactions (like the user in the referenced issue wants) because we don't have a system in place to pair hints with transactions

I'll take a look for alternatives