fix(ci): allow 90 minutes for ECS runner version resolution

.github/scripts/update-ecs-runner-qwen-workflow.test.mjs

@@ -124,6 +124,15 @@ describe('ECS runner qwen update workflow', () => {
     );
   });
 
+  it('pins the 90-minute resolve budget', () => {
+    const resolveJob = workflow.slice(
+      workflow.indexOf('  resolve:'),
+      workflow.indexOf('  update:'),
+    );
+    assert.ok(resolveJob.includes('timeout-minutes: 100'));
+    assert.ok(resolveJob.includes("RESOLVE_TIMEOUT_SECONDS: '5400'"));
+  });
+
   it('runs only when this workflow changes on main', () => {
     assert.ok(
       workflow.includes(

.github/workflows/update-ecs-runner-qwen.yml

@@ -25,7 +25,7 @@ jobs:
     name: 'Resolve version'
     if: "${{ github.repository == 'QwenLM/qwen-code' }}"
     runs-on: 'ubuntu-latest'
-    timeout-minutes: 30
+    timeout-minutes: 100
     outputs:
       version: '${{ steps.version.outputs.version }}'
     steps:
@@ -36,12 +36,11 @@ jobs:
           # npm publishes asynchronously: `npm publish --provenance` returns
           # "Your package is being processed and may take a few minutes to
           # become available", and release.yml dispatches this workflow as soon
-          # as it returns. For v0.22.3 the gap was ~16 minutes (published
-          # 17:14Z, resolvable 17:30Z), so the single un-retried `npm view` this
-          # step used to run 404'd on 3 of the 4 pools and left the fleet split
-          # across two CLI versions until a maintainer noticed. Wait the
-          # registry out rather than losing the race.
-          RESOLVE_TIMEOUT_SECONDS: '1500'
+          # as it returns. v0.23.0 took 55m22s to become resolvable, so the
+          # previous 25-minute budget expired while the package was still in
+          # flight. Wait up to 90 minutes and treat anything longer as an
+          # anomalous publish.
+          RESOLVE_TIMEOUT_SECONDS: '5400'
           RESOLVE_INTERVAL_SECONDS: '30'
         run: |-
           set -euo pipefail