You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[nextjs] api route not returning response or json once deployed to Vercel in latest 7.29.0 #6670
In the latest version, I am not getting json response from a 200 api route. There are no console logs though, the only way I found an error was via the component not loading as it awaits data from the api route before rendering.
I have deduced through updating one new package update at a time that Sentry SDK is the issue, and I suspect it has something to do with this:
feat(nextjs): Send events consistently on platforms that don't support streaming (#6578)
This is only happening once deployed to Vercel. Local work as intended. Downgrading to 7.28.1 api routes work as intended on both local and Vercel.
Expected Result
API routes return response as intended like in 7.28.1 when deployed to Vercel
Actual Result
Component doesn't load. I can't reproduce since this only happens on Vercel. There are no Sentry logs attached to this work yet either.
Hi, thanks for surfacing this. I see the update could indeed cause problems in the wrong circumstances - luckily for you, the fix is relatively straightforward!
First, the Problem: To be able to flush events before the lambda on Vercel or AWS terminates, the SDK needs to wrap res.{send,json,end}() and turn them into async functions. In the example you shared, you're calling res.json() and res.end() sequentially and because these functions are now basically async, their execution order may be reversed (V8 probably decides on the order).
We should probably introduce a mechanism that preserves the execution order - even though it is generally not advised to call both .json() and .end() for the same request - not just in combination with the Sentry SDK but in general. The fix is therefore simply not doing that. You're already doing that by having a return statement in front of some res.json() calls. You can simply add it to the 200 and 400 response code paths and everything should work again.
We'll investigate if we can find a solution for this behaviour out of the box but please try out the proposed fix and let me know if it worked!
@wadehammes We'll probably release a fix for this on Monday. Thanks again for reporting this! In the meanwhile, the workaround I described should still work. (PR if you're interested #6674)
@wadehammes We'll probably release a fix for this on Monday. Thanks again for reporting this! In the meanwhile, the workaround I described should still work. (PR if you're interested #6674)
awesome. that fix worked and is a lot more straightforward. thank you
Activity
wadehammes commentedon Jan 5, 2023
Here is a the api route in question:
lforst commentedon Jan 6, 2023
Hi, thanks for surfacing this. I see the update could indeed cause problems in the wrong circumstances - luckily for you, the fix is relatively straightforward!
First, the Problem: To be able to flush events before the lambda on Vercel or AWS terminates, the SDK needs to wrap
res.{send,json,end}()and turn them into async functions. In the example you shared, you're callingres.json()andres.end()sequentially and because these functions are now basically async, their execution order may be reversed (V8 probably decides on the order).We should probably introduce a mechanism that preserves the execution order - even though it is generally not advised to call both
.json()and.end()for the same request - not just in combination with the Sentry SDK but in general. The fix is therefore simply not doing that. You're already doing that by having areturnstatement in front of someres.json()calls. You can simply add it to the200and400response code paths and everything should work again.We'll investigate if we can find a solution for this behaviour out of the box but please try out the proposed fix and let me know if it worked!
wadehammes commentedon Jan 6, 2023
@lforst that is good to know! Ill refactor now and let you know.
lforst commentedon Jan 6, 2023
@wadehammes We'll probably release a fix for this on Monday. Thanks again for reporting this! In the meanwhile, the workaround I described should still work. (PR if you're interested #6674)
wadehammes commentedon Jan 6, 2023
awesome. that fix worked and is a lot more straightforward. thank you
lforst commentedon Jan 10, 2023
We just released a fix with version
7.30.0of the SDK.