TypeError: body used already for - should be able to extract twice
See original GitHub issueI unfortunately am calling a service which may or may not return JSON (or any) body data.
When I do the following, I get the TypeError: body used already for
error:
let data = null
try {
data = await res.json()
} catch (e) {
data = await res.text()
}
Two things:
- I should be able to call
.json() / .text()
multiple times - If the body is empty, it should just return null instead of throwing on
.text()
Issue Analytics
- State:
- Created 5 years ago
- Reactions:51
- Comments:8
Top Results From Across the Web
Zapier POST with error "body used already for" - Stack Overflow
Google says it's because of what I'm doing in the promise, by trying to read the res stream as text twice (note the...
Read more >Response.clone() - Web APIs - MDN Web Docs
clone() throws a TypeError if the response body has already been used. In fact, the main reason clone() exists is to allow multiple...
Read more >2. Issue - The Atlassian Developer Community
Here is the error. TypeError: body used already for: https://auth.atlassian.com/oauth/token. I followed this flow below and the error occurred ...
Read more >Errors | Node.js v19.3.0 Documentation
AssertionError s are a special class of error that can be triggered when Node.js detects an exceptional logic violation that should never occur....
Read more >The 10 Most Common JavaScript Issues Developers Face
If both functions defined inside replaceThing actually used priorThing , it would be important that they both get the same object, even if...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
The use-case from the beginning of the post is, imho, very normal and should be supported. I have just tried doing literally the same thing, and I believe many people think the same (probably because we are used to that try { JSON.parse } catch {} paradigm. It is not relevant to consumers of the library that there is some underlying stream etc. as implementation. This should work, all I’m saying…
the alternetive is that you only use
.text()
and then try to parse the json into a object usingJSON.parse(text)
Maybe also worth having a look at some of the headers you get back. eg
content-length
,content-type
that matchapplication/json
look also ifres.ok
is true or false before you continue down the path