fix: Remove Sentry keys from cached HTTP request headers #1975
Conversation
This file contains 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
When an HTTP request is happening without a span, it used to just reuse the existing headers, which can include an old and unrelated traceId. This caused weird behavior where the request would seem to happen from a totally different part of the app. Fixes #1827
* master: release: 7.21.0
brustolin
approved these changes
Jul 15, 2022
Comment on lines
+287
to
+289
| NSMutableDictionary *existingHeaders = headers.mutableCopy; | ||
| [existingHeaders removeObjectsForKeys:@[ SENTRY_TRACE_HEADER, SENTRY_BAGGAGE_HEADER ]]; | ||
| return [existingHeaders copy]; |
There was a problem hiding this comment.
Please just add a comment here why we removing the header.
Because NSURLSession itself caches its, and were good to go.
|
Thanks @kevinrenskers 馃憣 |
kevinrenskers
added a commit
that referenced
this pull request
Jul 18, 2022
* master: ref: Fix linter error (#1981) fix: read free_memory when the event is captured, not only at SDK startup (#1962) fix: Remove Sentry keys from cached HTTP request headers (#1975) release: 7.21.0 ci: Don't run benchmarks on release (#1971) Don't track OOMs for simulators (#1970) feat: Automatic nest new spans with the ui life cycle function (#1959) docs: update some docs/comments to read a little better (#1966) ci: benchmarking updates (#1926) feat: upload list of slow/frozen rendered frame timestamps during a profile (#1910)
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.
馃摐 Description
When an HTTP request is happening without a span, it used to just reuse the existing headers, which can include an old and unrelated traceId. This caused weird behavior where the request would seem to happen from a totally different part of the app.
馃挕 Motivation and Context
The root cause of the bug as described in #1827 was actually user error, by doing the HTTP request in a new transaction that wasn't bound to the scope at all. Contrast to the initial request which was done in the scope of
viewDidLoad, which does get an automatic transaction added to the scope. But because the 2nd request happened with anilvalue forSentrySDK.currentHub.scope.span, the headers from the first request were sent along with the second request (cached byNSURLSessionitself!).By scrubbing the cached headers of the Sentry keys, we can prevent the weird behavior as described in the issue, and it'll make it more obvious to the user when the request doesn't show up as part of the trace at all.
Dhiogo and I came to this conclusion/solution together.
Fixes #1827
馃挌 How did you test it?
Unit test
馃摑 Checklist
馃敭 Next steps