fix: use atomic write for engine.stamp to prevent race conditions

[b055man]

Description

This PR fixes a race condition that occurs when multiple Flutter commands (e.g., parallel flutter pub get executions via tools like melos) are run concurrently.

Previously, bin/internal/update_engine_version.sh and .ps1 wrote to bin/cache/engine.stamp directly. If one process truncated the file for writing at the exact microsecond another process was reading it, the reader would receive an empty string. This caused the Flutter tool to construct a malformed URL for the engine stamp download (e.g., https://storage.googleapis.com/flutter_infra_release/flutter//engine_stamp.json), resulting in a 404 error that randomly broke CI pipelines and local builds.

Changes:

• Modified update_engine_version.sh and update_engine_version.ps1 to use an atomic write pattern (writing the engine hash to a temporary file, then atomically moving/renaming it to engine.stamp).
• Added a stress test in dev/tools/test/update_engine_version_test.dart that deliberately spawns 20 concurrent writers while constantly reading the stamp file to guarantee that a successful read never returns an empty string.

Issues fixed

Fixes #184027

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request updates the update_engine_version scripts (PowerShell and shell) to write the engine version to engine.stamp atomically, using a temporary file and an atomic move operation. This change aims to prevent race conditions during parallel Flutter executions. A new Dart test has been added to verify this atomic behavior under concurrent write scenarios. The review suggests improving the robustness of temporary file cleanup in both scripts: by using a try...finally block in the PowerShell script and a trap in the shell script to ensure temporary files are removed even if the scripts exit unexpectedly.

[gemini-code-assist]

To prevent leaving temporary files in the cache directory if an error occurs (e.g., during the Move-Item operation), it's more robust to wrap the file operations in a try...finally block. The finally block ensures the temporary file is always cleaned up.

$esTmp = "$flutterRoot/bin/cache/engine.stamp.tmp.$PID"
try {
    Set-Content -Path $esTmp -Value $engineVersion -Encoding Ascii
    Move-Item -Path $esTmp -Destination "$flutterRoot/bin/cache/engine.stamp" -Force
} finally {
    if (Test-Path -Path $esTmp) {
        Remove-Item -Path $esTmp -Force
    }
}

[jtmcdole]

powershell 5.1 has try finally? that's neat.

[gemini-code-assist]

For improved robustness, it's best to use a trap to ensure the temporary file is cleaned up if the script exits unexpectedly. This prevents leaving stale .tmp files in the cache directory.

Additionally, you can inline the process ID ($$) for conciseness.

Suggested change

	pid=$$
	_es_tmp="$FLUTTER_ROOT/bin/cache/engine.stamp.tmp.$pid"
	echo "$ENGINE_VERSION" >"$_es_tmp" && mv "$_es_tmp" "$FLUTTER_ROOT/bin/cache/engine.stamp"
	_es_tmp="$FLUTTER_ROOT/bin/cache/engine.stamp.tmp.$$"
	trap 'rm -f "$_es_tmp"' EXIT
	echo "$ENGINE_VERSION" >"$_es_tmp" && mv "$_es_tmp" "$FLUTTER_ROOT/bin/cache/engine.stamp"
	trap - EXIT

[b055man]

@jtmcdole

Additionally, you can inline the process ID ($$) for conciseness.

What's your stance on this one?

[jtmcdole]

I like pid=$$ so its clear to anyone else reading this, absent that I would argue for a # Generate a temp file using the $$ pid

[jtmcdole]

What do you think about the trap/try-finally?

[b055man]

What do you think about the trap/try-finally?

@jtmcdole I think they definitely make sense. I'll update the PR.

[b055man]

@jtmcdole I updated the PR, adressing linter / formatting issues, adding logic for temp file removal for both ps1 and bash scripts. Additionally, the powershell script now actually has some additional logic to account for potential exceptions (it does not guarantee success on Windows though, as Move-Item -Force is not atomic, only attempts to reduce a chance of an error).
I'm actually considering skipping the newly added test when running it on Windows as I suspect it may still have a potential for being flaky (do you know how to trigger the pipeline again to run all the checks?).

[jtmcdole]

[auto-submit]

autosubmit label was removed for flutter/flutter/184131, because This PR has not met approval requirements for merging. The PR author is not a member of flutter-hackers and needs 2 more review(s) in order to merge this PR.

• Merge guidelines: A PR needs at least one approved review if the author is already part of flutter-hackers or two member reviews if the author is not a flutter-hacker before re-applying the autosubmit label. Reviewers: If you left a comment approving, please use the "approve" review action instead.