Incorrect caching

### Link to the code that reproduces this issue https://github.com/mastoj/more-cache-experiments ### To Reproduce 1. Build app and start 2. Open http://localhost:3000/cache/a/b/c and http://localhost:3000/revalidate in two different tabs (tab A and B) 3. Refresh tab A over and over again until the first time stamp changes, which is as expected 4. Wait 5 seconds and click "Revalidate A" in tab B 5. Go back to refreshing tab A over and over again until both timestamp changes (you can test on the deployed version here https://more-cache-experiments.vercel.app/cache/a/b, https://more-cache-experiments.vercel.app/revalidate) ### Current vs. Expected behavior ### Current behavior: What happens when you click "Revalidate A" seems to be that the next time the page will be revalidated is based on the revalidation time only on the "refreshed" fetch calls. This leads to the second timestamp being updated later than it should be. This could lead to weird scenarios when having long revalidation times I think. ### Expected behavior: A little bit tricky, but I think the expected behavior should be to set a new revalidation time for the page to be the lowest of the times for newly calculated value and the existing one, but I'm not 100% that is correct. ### Provide environment information ```bash Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 23.5.0: Wed May 1 20:14:38 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6020 Available memory (MB): 65536 Available CPU cores: 12 Binaries: Node: 18.17.0 npm: 10.8.2 Yarn: 1.22.21 pnpm: 9.1.0 Relevant Packages: next: 14.2.5 // Latest available version is detected (14.2.5). eslint-config-next: 14.2.5 react: 18.3.1 react-dom: 18.3.1 typescript: 5.5.4 Next.js Config: output: N/A ``` ### Which area(s) are affected? (Select all that apply) Not sure ### Which stage(s) are affected? (Select all that apply) next start (local), Vercel (Deployed) ### Additional context _No response_