fix(http): propagate plain errors when parsing fails#62765
Closed
sbarfurth wants to merge 1 commit intoangular:mainfrom
Closed
fix(http): propagate plain errors when parsing fails#62765sbarfurth wants to merge 1 commit intoangular:mainfrom
sbarfurth wants to merge 1 commit intoangular:mainfrom
Conversation
Member
|
Could you please reword the commit, the scope should be |
The fetch backend now propagates the plain body when parsing the body fails. This replicates the behavior of the XHR backend introduced in angular#19773. The current state completely obfuscates errors of the "wrong" response type. However, it's not uncommon for successful requests to return one type and errors to return another type. Propagating the plain error allows downstream error consumers to reason about the error body and decide how to parse it depending on application needs.
9f20569 to
646d4c1
Compare
Contributor
Author
Done, sorry about that. |
JeanMeche
approved these changes
Jul 23, 2025
mmalerba
approved these changes
Jul 23, 2025
thePunderWoman
pushed a commit
that referenced
this pull request
Jul 24, 2025
The fetch backend now propagates the plain body when parsing the body fails. This replicates the behavior of the XHR backend introduced in #19773. The current state completely obfuscates errors of the "wrong" response type. However, it's not uncommon for successful requests to return one type and errors to return another type. Propagating the plain error allows downstream error consumers to reason about the error body and decide how to parse it depending on application needs. PR Close #62765
Contributor
|
This PR was merged into the repository by commit 1b73c23. The changes were merged into the following branches: main, 20.1.x |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a 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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 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.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
When the
responseTypeis set tojsonand the fetch backend is active, the response body will always be parsed as JSON, regardless of whether it is a success or error response. However, it's not uncommon for successful requests to return one type and errors to return another type. The current implementation will fail parsing in this case and forward only the resultingSyntaxErroronHttpErrorResponse.error. This obfuscates the source error body entirely to downstream response consumers.Issue Number: N/A
What is the new behavior?
The fetch backend now propagates the plain body when parsing the body fails. This replicates the behavior of the XHR backend introduced in #19773.
Propagating the plain error allows downstream error consumers to reason about the error body and decide how to parse it depending on application needs.
Does this PR introduce a breaking change?
I'm unsure if you'd consider this breaking. The previous implementation exposed relatively useless
SyntaxError, but people may be relying on these for some reason?