Best answer

skipThrowForStatus: true throws anyway (z.request)

  • 7 September 2022
  • 4 replies
  • 421 views

Userlevel 1
Badge +1

I’m having a hard time testing the `z.request()` in combination with the `skipThrowForStatus: true` setting.

My understanding from running on the Zapier platform is, that it does not throw an Error but returns the response instead.

However running with `zapier test` the following code with the node platform (current zapier-platform-core@12.0.3):

    const results = await appTester(async (z, bundle) => {
for (let step = 0; step < 100; step++) {
console.log(step)
/** @type {ZapierZRequestResponse} */
try {
const response = await z.request({
url: `${bundle.authData.server}/api/endpoint/`,
headers: {Authorization: `Token ${bundle.authData.api_token}`},
skipThrowForStatus: true,
})
} catch (e) {
const ee = e
}
}
return null
}, bundle)

it always throws on a 4xx. But the reason to test here is to actually provoke the error and then handle it for which the HTTP response unfiltered is required and for which I thought skipThrowForStatus: true was appropriate.

Is there a way to make use of that request option property within tests?

icon

Best answer by toktok 7 September 2022, 08:48

View original

This post has been closed for comments. Please create a new post if you need help or have a question about this topic.

4 replies

Userlevel 1
Badge +1

Found it myself: z.request() is delegating to the http middleware defined per the test-app in AppTester and that one was not looking into that attribute and then always throwing (so our own code did the throw).

Fix is to handle the case on looking into response.request.skipThrowForStatus there.

/* HTTP Middleware */
const handleHTTPError = (response, z) => {
if (response.request.skipThrowForStatus) {
return response
}
// ... standard error handling code ...
}

References:

Userlevel 6
Badge +8

Nice work figuring this one out, @toktok !

You’re not the only person to get confused about this. I’ll drop one more link here for anybody else who finds this, and that’s for the CLI changelog at version 10, where we introduced a change to how the middleware was/wasn’t called and this change could break existing error-handling code if folks weren’t careful.

Definitely let us know if you have any more questions!

Userlevel 1
Badge +1

Sure, and thanks @shalgrim. Btw., this is why I put the core version in, and Yes! having the change-log entry is a great addition, too.

And to add up to it, this is also another context reference I found useful yesterday, editing it in now:

Userlevel 6
Badge +8

Together you and I will re-document everything! 😁