macos-14 brownouts from Oct 5: rerun a Sume submit with the same key

If a GitHub Actions workflow submits a Sume job from a macos-14 runner, the brownouts that start on 2026-10-05 will fail some runs, and re-running them is safe only if the submit carries an Idempotency-Key that is the same on every attempt. Sume's docs say a retried submit with the same key returns the original job instead of billing a second one, and that reusing a key for a different payload returns 409 idempotency_conflict.

GitHub's dates and labels are from its macOS 14 retirement notice; Sume's behavior is from Jobs and results, Generation admission and Errors and rate limits, read 2026-10-03. The notice says jobs on these labels will temporarily fail during the scheduled brownouts; it does not say at which step a job stops, so the design below assumes any step can be the last one that ran.

When are the brownouts?

Retirement is 2026-11-02 for macos-14, macos-14-large and macos-14-xlarge. GitHub lists eight October brownout windows, each starting at 14:00 UTC and ending at 00:00 UTC the next day, and warns it may also reduce capacity, which means longer queue times. The recommended replacements are macos-latest (macOS 26), macos-15, macos-latest-xlarge and macos-15-xlarge.

What should the idempotency key be?

Build it from values that stay constant across a re-run and that identify the intent, for example the repository, the workflow's run id and the step name. GitHub's run_id stays the same on a re-run while run_attempt increases, so leave the attempt number out of the key (this is GitHub's documented behavior for the github context; I did not re-fetch that page for this post). Put the exact request body in a file or a step output so a re-run sends the same bytes, not a freshly timestamped prompt.

If a run died after the submit reached Sume, the re-run's submit returns the original job. Then do not stop at the submit response: read status_url, honor next_poll_after_seconds, and fetch the result when result_ready is true.

What if the queue is full when the re-run lands?

A re-run burst after a brownout can submit many jobs at once. Sume accepts valid jobs as queued while queue capacity remains and answers 429 queue_full when it does not; the docs say to retry with the same key after capacity opens, and 429 rate_limited is separate (back off with retry-after). Check generation_limits.queue_capacity_remaining in submit responses and stop adding work when it is low.