next.js

9da349b7 - Turbopack: wait for trace file changes after format errors (#99847)

Turbopack: wait for trace file changes after format errors (#99847) ### What? `turbo-trace-server` no longer re-reads a trace file every 500 ms after it was rejected with a format error. It prints the error once, prints `Waiting for the trace file to change...`, and reads the file again only once it changes (different size, modification or creation time, or on unix a different file at the path) or is removed. ### Why? `TraceReader::try_read` returned `true` after printing `Trace file error: ...`, so `TraceReader::run` slept 500 ms and read the whole file again, forever. With the `TRACEv1` header check (#99781), every old `TRACEv0` trace hit this: the server printed the same error twice a second (10 times in 5 s locally). Corrupt trace data behaved the same way. ### How? - Both format-error paths (format detection, and decoding with `format.read`) take a metadata snapshot of the open file and poll the path's metadata once per second until it differs. Only metadata is compared, so a rewrite that keeps size and timestamps the same (and on unix the same file) isn't noticed. - Valid traces, live tailing, I/O errors and `STOP_AT` behave as before. ### Verification - New unit test: a `TRACEv0` file and a corrupt `TRACEv1` file are not read again for 2.5 s, and replacing them with a valid trace loads it. It failed before this change. - New unit test for change detection: size change, same-size rewrite, replacement by another file, and removal. - Manual, release `turbo-trace-server`: - `TRACEv0` file for 5 s: error printed once (before: 10 times). - Corrupt `TRACEv1` file for 3 s: error printed once (before: 6 times). - Replacing a rejected `TRACEv0` file with a real `TRACEv1` trace while the server runs loads all 39,490 spans without a restart. - Only run locally on Linux; Windows and macOS are covered by CI. <!-- NEXT_JS_LLM --> <!-- fleet 4a52842b-f1a2-43cb-9779-3655caada6a0 --> Co-authored-by: vercel-fleet-prod[bot] <318278635+vercel-fleet-prod[bot]@users.noreply.github.com> Co-authored-by: Tobias Koppers <1365881+sokra@users.noreply.github.com>