-
Type:
Task
-
Resolution: Won't Do
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: evergreen.yml
-
None
-
200
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
- Summary
Fixes [BF-44144](https://jira.mongodb.org/browse/BF-44144): `multiversion_future_git_tag` tasks on `enterprise-rhel-8-64-bit-future-git-tag-multiversion` system-fail during `do multiversion setup` with `403 Request has expired` / `DownloadError: URL to download is absent`.
*Root cause:* On the future-git-tag variant the last-continuous binaries are this commit's own compile artifacts (from `linux-x86-dynamic-compile-future-tag-multiversion-last-continuous`). `multiversion_selection.sh` (run once per variant in `select_multiversion_binaries`) resolved their download URL into `multiversion-downloads.json`. Because compile artifacts are uploaded with `visibility: signed`, the Evergreen API returns a presigned S3 URL that expires after 900 seconds (`X-Amz-Expires=900` in the failure logs). Generated test tasks consume the JSON minutes to hours later, and db-contrib-tool uses the stored URL verbatim (no re-resolution for versions-file requests), so any task starting more than 15 minutes after selection fails. There is no public release fallback for a master commit, hence the hard failure. Other variants are unaffected because their entries fall back to public `downloads.mongodb.org` URLs.
*Fix:* Resolve the last-continuous binaries at setup time instead of selection time, so each task gets a freshly signed URL:
- `evergreen/multiversion_selection.sh`: no longer bakes the future-git-tag last-continuous URL into `multiversion-downloads.json`.
- `evergreen/multiversion_setup.sh`: when `multiversion_last_continuous_variant` is set, run `db-contrib-tool setup-repro-env ${version_id}=last-continuous --variant ...` directly.
- `etc/evergreen_yml_components/definitions.yml`: add `configure evergreen api credentials` to `do multiversion setup` so db-contrib-tool can query the Evergreen API at setup time (same as the selection task).
Behavior on all other variants is unchanged (`multiversion_last_continuous_variant` unset skips the new block).
*Note:* the same staleness hazard exists for the `last_lts_evg_version_id`/`last_continuous_evg_version_id` pinning path; left out of scope here since those artifacts have public release fallbacks on the branch projects that use them.