-
Notifications
You must be signed in to change notification settings - Fork 27.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
micro fix of the cache limit check #60249
micro fix of the cache limit check #60249
Conversation
Allow CI Workflow Run
Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer |
2 similar comments
Allow CI Workflow Run
Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer |
Allow CI Workflow Run
Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like we don't have a test for this error in dev so if you'd be interested in adding that in a follow-up that'd be great
Stats from current PRDefault BuildGeneral
Client Bundles (main, webpack)
Legacy Client Bundles (polyfills)
Client Pages
Client Build Manifests
Rendered Page Sizes
Edge SSR bundle Size
Middleware size
Next Runtimes
Diff detailsDiff for page.jsDiff too large to display Diff for edge-ssr.jsDiff too large to display Diff for server.runtime.prod.jsDiff too large to display |
### Fixing a bug I'm sorry, I have no idea how I managed to delete this, as I just copied the code. However, I had to figure out why the tests passed. When I test the running application locally, it works as expected. So, when a route is first used in a running production application in a test, `ctx.fetchCache` is `undefined`. Therefore, the error rule does not trigger on the first request, and the cache is successfully written. This may result in artifacts in FetchCache in Vercel and possibly in other parts of the code. ```ts if ( ctx.fetchCache && // <- Undefined on first request // we don't show this error/warning when a custom cache handler is being used // as it might not have this limit !this.hasCustomCacheHandler && JSON.stringify(data).length > 2 * 1024 * 1024 ) { if (this.dev) { throw new Error(`fetch for over 2MB of data can not be cached`) } return } ``` I'm 95% sure that this is a bug and it shouldn't work like this. I'll look into this later and if there is an error, I'll put it into a task and try to figure it out later. Unfortunately, the [test](https://github.com/vordgi/next.js/blob/7e028fb6d8598cfcca8de514e4608374f931c973/test/e2e/app-dir/app-static/app-static.test.ts#L3080) from [previous PR](vercel#59976) is not working yet, although it is correct from my point of view. I think it should be kept and the problem above should be fixed. Co-authored-by: JJ Kasper <[email protected]>
### What? In the previous PR (#60249), it was found that the case when the response size is larger than 2MB is not sufficiently covered by tests [[comment](#60249 (review))] ### How? I added a few more checks. Just checking the number of API calls is not enough - I believe it is important to additionally verify what exactly the page received. If I'm honest, I couldn't find the exact reason why data is loaded after application start when using `customCacheHandler`, but without it - during build. It seems like something in the butcher. Therefore, in this part, I simply configured it for the current version. --------- Co-authored-by: JJ Kasper <[email protected]>
Fixing a bug
I'm sorry, I have no idea how I managed to delete this, as I just copied the code.
However, I had to figure out why the tests passed. When I test the running application locally, it works as expected.
So, when a route is first used in a running production application in a test,
ctx.fetchCache
isundefined
. Therefore, the error rule does not trigger on the first request, and the cache is successfully written. This may result in artifacts in FetchCache in Vercel and possibly in other parts of the code.I'm 95% sure that this is a bug and it shouldn't work like this. I'll look into this later and if there is an error, I'll put it into a task and try to figure it out later.
Unfortunately, the test from previous PR is not working yet, although it is correct from my point of view. I think it should be kept and the problem above should be fixed.