Ensure API route errors are propagated in minimal mode #26875
Merged
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
ijjk
requested review from
huozhi,
padmaia,
shuding,
styfle and
timneutkens
as code owners
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
styfle
approved these changes
Jul 2, 2021
Stats from current PRDefault Build (Decrease detected ✓)General Overall increase
|
| vercel/next.js canary | ijjk/next.js fix/api-error-bubbling | Change | |
|---|---|---|---|
| buildDuration | 11.2s | 11.2s | -57ms |
| buildDurationCached | 2.8s | 2.7s | -50ms |
| nodeModulesSize | 49.3 MB | 49.3 MB |
Page Load Tests Overall decrease ⚠️
| vercel/next.js canary | ijjk/next.js fix/api-error-bubbling | Change | |
|---|---|---|---|
| / failed reqs | 0 | 0 | ✓ |
| / total time (seconds) | 1.997 | 2.017 | |
| / avg req/sec | 1251.61 | 1239.55 | |
| /error-in-render failed reqs | 0 | 0 | ✓ |
| /error-in-render total time (seconds) | 1.084 | 1.121 | |
| /error-in-render avg req/sec | 2305.72 | 2231.04 |
Client Bundles (main, webpack, commons)
| vercel/next.js canary | ijjk/next.js fix/api-error-bubbling | Change | |
|---|---|---|---|
| 359.HASH.js gzip | 3.09 kB | 3.09 kB | ✓ |
| framework-HASH.js gzip | 42 kB | 42 kB | ✓ |
| main-HASH.js gzip | 20.2 kB | 20.2 kB | ✓ |
| webpack-HASH.js gzip | 1.49 kB | 1.49 kB | ✓ |
| Overall change | 66.9 kB | 66.9 kB | ✓ |
Legacy Client Bundles (polyfills)
| vercel/next.js canary | ijjk/next.js fix/api-error-bubbling | Change | |
|---|---|---|---|
| polyfills-HASH.js gzip | 31.1 kB | 31.1 kB | ✓ |
| Overall change | 31.1 kB | 31.1 kB | ✓ |
Client Pages
| vercel/next.js canary | ijjk/next.js fix/api-error-bubbling | Change | |
|---|---|---|---|
| _app-HASH.js gzip | 803 B | 803 B | ✓ |
| _error-HASH.js gzip | 3.18 kB | 3.18 kB | ✓ |
| amp-HASH.js gzip | 526 B | 526 B | ✓ |
| css-HASH.js gzip | 329 B | 329 B | ✓ |
| hooks-HASH.js gzip | 903 B | 903 B | ✓ |
| index-HASH.js gzip | 263 B | 263 B | ✓ |
| link-HASH.js gzip | 1.65 kB | 1.65 kB | ✓ |
| routerDirect..HASH.js gzip | 322 B | 322 B | ✓ |
| withRouter-HASH.js gzip | 320 B | 320 B | ✓ |
| bb14e60e810b..30f.css gzip | 125 B | 125 B | ✓ |
| Overall change | 8.42 kB | 8.42 kB | ✓ |
Client Build Manifests
| vercel/next.js canary | ijjk/next.js fix/api-error-bubbling | Change | |
|---|---|---|---|
| _buildManifest.js gzip | 390 B | 390 B | ✓ |
| Overall change | 390 B | 390 B | ✓ |
Rendered Page Sizes
| vercel/next.js canary | ijjk/next.js fix/api-error-bubbling | Change | |
|---|---|---|---|
| index.html gzip | 523 B | 523 B | ✓ |
| link.html gzip | 535 B | 535 B | ✓ |
| withRouter.html gzip | 515 B | 515 B | ✓ |
| Overall change | 1.57 kB | 1.57 kB | ✓ |
Webpack 4 Mode (Increase detected ⚠️ )
General Overall increase ⚠️
| vercel/next.js canary | ijjk/next.js fix/api-error-bubbling | Change | |
|---|---|---|---|
| buildDuration | 9.9s | 10s | |
| buildDurationCached | 4s | 4s | -34ms |
| nodeModulesSize | 49.3 MB | 49.3 MB |
Page Load Tests Overall increase ✓
| vercel/next.js canary | ijjk/next.js fix/api-error-bubbling | Change | |
|---|---|---|---|
| / failed reqs | 0 | 0 | ✓ |
| / total time (seconds) | 2.041 | 2.019 | -0.02 |
| / avg req/sec | 1224.93 | 1237.96 | +13.03 |
| /error-in-render failed reqs | 0 | 0 | ✓ |
| /error-in-render total time (seconds) | 1.154 | 1.124 | -0.03 |
| /error-in-render avg req/sec | 2165.69 | 2223.34 | +57.65 |
Client Bundles (main, webpack, commons)
| vercel/next.js canary | ijjk/next.js fix/api-error-bubbling | Change | |
|---|---|---|---|
| 14.HASH.js gzip | 3.11 kB | 3.11 kB | ✓ |
| 677f882d2ed8..HASH.js gzip | 13.4 kB | 13.4 kB | ✓ |
| framework.HASH.js gzip | 41.8 kB | 41.8 kB | ✓ |
| main-HASH.js gzip | 8.07 kB | 8.07 kB | ✓ |
| webpack-HASH.js gzip | 1.19 kB | 1.19 kB | ✓ |
| Overall change | 67.5 kB | 67.5 kB | ✓ |
Legacy Client Bundles (polyfills)
| vercel/next.js canary | ijjk/next.js fix/api-error-bubbling | Change | |
|---|---|---|---|
| polyfills-HASH.js gzip | 31.3 kB | 31.3 kB | ✓ |
| Overall change | 31.3 kB | 31.3 kB | ✓ |
Client Pages
| vercel/next.js canary | ijjk/next.js fix/api-error-bubbling | Change | |
|---|---|---|---|
| _app-HASH.js gzip | 1.07 kB | 1.07 kB | ✓ |
| _error-HASH.js gzip | 3.83 kB | 3.83 kB | ✓ |
| amp-HASH.js gzip | 531 B | 531 B | ✓ |
| css-HASH.js gzip | 333 B | 333 B | ✓ |
| hooks-HASH.js gzip | 910 B | 910 B | ✓ |
| index-HASH.js gzip | 227 B | 227 B | ✓ |
| link-HASH.js gzip | 1.64 kB | 1.64 kB | ✓ |
| routerDirect..HASH.js gzip | 295 B | 295 B | ✓ |
| withRouter-HASH.js gzip | 292 B | 292 B | ✓ |
| e025d2764813..52f.css gzip | 125 B | 125 B | ✓ |
| Overall change | 9.26 kB | 9.26 kB | ✓ |
Client Build Manifests
| vercel/next.js canary | ijjk/next.js fix/api-error-bubbling | Change | |
|---|---|---|---|
| _buildManifest.js gzip | 418 B | 418 B | ✓ |
| Overall change | 418 B | 418 B | ✓ |
Rendered Page Sizes
| vercel/next.js canary | ijjk/next.js fix/api-error-bubbling | Change | |
|---|---|---|---|
| index.html gzip | 567 B | 567 B | ✓ |
| link.html gzip | 580 B | 580 B | ✓ |
| withRouter.html gzip | 559 B | 559 B | ✓ |
| Overall change | 1.71 kB | 1.71 kB | ✓ |
flybayer
pushed a commit
to blitz-js/next.js
that referenced
this pull request
Aug 19, 2021
This ensures when an error occurs in an API route while using minimal mode the error is bubbled so it can be handled at the top-level ## Bug - [ ] Related issues linked using `fixes #number` - [x] Integration tests added - [ ] Errors have helpful link attached, see `contributing.md`
lobsterkatie
added a commit
to getsentry/sentry-javascript
that referenced
this pull request
Nov 15, 2021
In our nextjs API route wrapper `withSentry`, we capture any errors thrown by the original handler, and then once we've captured them, we rethrow them, so that our capturing of them doesn't interfere with whatever other error handling might go on. Until recently, that was fine, as nextjs didn't actually propagate the error any farther, and so it didn't interfere with our processing pipeline and didn't prevent `res.end()` (on which we rely for finishing the transaction and flushing events to Sentry) from running. However, Vercel released a change[1] which caused said errors to begin propagating if the API route is running on Vercel. (Technically, it's if the server is running in minimal mode, but all API handlers on vercel do.) A side effect of this change is that when there's an error, `res.end()` is no longer called. As a result, the SDK's work is cut short, and neither errors in API route handlers nor transactions tracing such routes make it to Sentry. This fixes that, by moving the work of finishing the transaction and flushing events into its own function and calling it not only in `res.end()` but also before we rethrow the error. (Note: In the cases where there is an error and the server is not running in minimal mode, this means that function will be hit twice, but that's okay, since the second time around it will just no-op, since `transaction.finish()` bails immediately if the transaction is already finished, and `flush()` returns immediately if there's nothing to flush.) H/t to @jmurty for his work in #4044, which helped me fix some problems in my first approach to solving this problem. Fixes #3917. [1] vercel/next.js#26875
lobsterkatie
added a commit
to getsentry/sentry-javascript
that referenced
this pull request
Nov 15, 2021
In our nextjs API route wrapper `withSentry`, we capture any errors thrown by the original handler, and then once we've captured them, we rethrow them, so that our capturing of them doesn't interfere with whatever other error handling might go on. Until recently, that was fine, as nextjs didn't actually propagate the error any farther, and so it didn't interfere with our processing pipeline and didn't prevent `res.end()` (on which we rely for finishing the transaction and flushing events to Sentry) from running. However, Vercel released a change[1] which caused said errors to begin propagating if the API route is running on Vercel. (Technically, it's if the server is running in minimal mode, but all API handlers on vercel do.) A side effect of this change is that when there's an error, `res.end()` is no longer called. As a result, the SDK's work is cut short, and neither errors in API route handlers nor transactions tracing such routes make it to Sentry. This fixes that, by moving the work of finishing the transaction and flushing events into its own function and calling it not only in `res.end()` but also before we rethrow the error. (Note: In the cases where there is an error and the server is not running in minimal mode, this means that function will be hit twice, but that's okay, since the second time around it will just no-op, since `transaction.finish()` bails immediately if the transaction is already finished, and `flush()` returns immediately if there's nothing to flush.) H/t to @jmurty for his work in #4044, which helped me fix some problems in my first approach to solving this problem. Fixes #3917. [1] vercel/next.js#26875
onurtemizkan
pushed a commit
to getsentry/sentry-javascript
that referenced
this pull request
Dec 19, 2021
In our nextjs API route wrapper `withSentry`, we capture any errors thrown by the original handler, and then once we've captured them, we rethrow them, so that our capturing of them doesn't interfere with whatever other error handling might go on. Until recently, that was fine, as nextjs didn't actually propagate the error any farther, and so it didn't interfere with our processing pipeline and didn't prevent `res.end()` (on which we rely for finishing the transaction and flushing events to Sentry) from running. However, Vercel released a change[1] which caused said errors to begin propagating if the API route is running on Vercel. (Technically, it's if the server is running in minimal mode, but all API handlers on vercel do.) A side effect of this change is that when there's an error, `res.end()` is no longer called. As a result, the SDK's work is cut short, and neither errors in API route handlers nor transactions tracing such routes make it to Sentry. This fixes that, by moving the work of finishing the transaction and flushing events into its own function and calling it not only in `res.end()` but also before we rethrow the error. (Note: In the cases where there is an error and the server is not running in minimal mode, this means that function will be hit twice, but that's okay, since the second time around it will just no-op, since `transaction.finish()` bails immediately if the transaction is already finished, and `flush()` returns immediately if there's nothing to flush.) H/t to @jmurty for his work in #4044, which helped me fix some problems in my first approach to solving this problem. Fixes #3917. [1] vercel/next.js#26875
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
This ensures when an error occurs in an API route while using minimal mode the error is bubbled so it can be handled at the top-level
Bug
fixes #numbercontributing.md