Marking as a P2 as it has an easy workaround: provide an bin/internal/engine.version.

As part of the monorepo, the engine SHA is determined by a flowchart, flutter.dev/to/engine-artifacts. There is a flaw in the current implementation - only Cocoon knows about FLUTTER_PREBUILT_ENGINE_VERSION (and friends), so if a non-Cocoon scheduler runs a task that needs a Flutter engine (or in this case, Dart SDK), it will use a very outdated (and possibly incorrect) engine SHA.

We didn't notice this before because we've been accidentally skipping Linux docs_publish for months.

See https://flutter-dashboard.appspot.com/#/build?repo=flutter&branch=flutter-3.33-candidate.0:

Note that the build for f43bd5c has failed.

A particular build framework > display builds > Linux docs_publish fails to download the Dart SDK:

Downloading Linux x64 Dart SDK from Flutter engine 9662d86a7da134a4db79551e6354df551dd4ff34...
...

Where does that SHA come from? It's 9662d86, which was the initial commit to create 3.33-candidate.0, and the build had timed out due to resource contention with another build. In this particular case the local fix is easy - re-run that (previously) failing build so that 9662d86 has an uploaded engine, but it showed a flaw in the current release builder: tasks that are dependent on an engine use the branched engine SHA.

If Linux docs_publish (or similar, such as Linux docs_deploy_*) needed a newer version of say, the Dart SDK, there would be no way to fix this without modifying the release builder, or setting engine.version. In most cases engine.version would be set, but it could confuse the release team.

Should we provide FLUTTER_PREBUILT_ENGINE_VERSION to the builders, with similar logic to Cocoon?

/cc @jtmcdole for thoughts.