build(deps): bump taskcluster from 97.1.0 to 99.2.1 in /bot

[dependabot]

Bumps taskcluster from 97.1.0 to 99.2.1.

Release notes

Sourced from taskcluster's releases.

v99.2.1

GENERAL

▶ [patch] #8525 Fix two related races that could leave a Taskcluster task in an inconsistent state when a Pulse publish failed during task creation or a run state transition:

• A run could transition to pending in tasks.runs without a corresponding queue_pending_tasks row, making the task invisible to workers and to the "pending tasks" UI/API counts. Transitions of a run to pending (schedule_task, rerun_task, resolve_task, check_task_claim) now commit the queue_pending_tasks row in the same database transaction as the tasks.runs update.
• A task could be inserted into tasks without a corresponding queue_task_deadlines row, leaving it untracked by the deadline resolver. createTask now inserts both rows atomically inside create_task_atomic.

In the queue's HTTP API handlers (createTask, scheduleTask, rerunTask, reportException), Pulse taskPending / taskException / taskDefined publishes that follow these now-atomic DB commits are best-effort: the database is the source of truth, so a Pulse publish failure no longer fails the operation. Consumers that need exact-once notification should treat Pulse as advisory and read queue.task(taskId).status for the authoritative state. Background resolvers (claim-resolver, worker-removed-resolver, dependency-resolver) preserve their pre-existing at-least-once publish semantics by continuing to fail the handler on Pulse error so redelivery re-attempts the publish.

USERS

▶ [patch] Update sha2 dependency in the rust client

OTHER

▶ Additional changes not described here: bug 2035431, #5457.

v99.2.0

DEPLOYERS

▶ [minor] #8243 Add optional Kubernetes Gateway API support (Gateway, HTTPRoute, HealthCheckPolicy) as an alternative to the existing Ingress resource. These new resources are only rendered when ingressType: gateway is set in Helm values, so existing Ingress-based deployments are unaffected and no new CRDs or skipResourceTypes entries are required.

To adopt Gateway API for traffic routing, set ingressType: gateway along with gatewayClassName, and for GKE regional external ALBs, gatewayStaticIpName and gcpManagedCertName. Both Ingress and Gateway API resources will be rendered side-by-side, letting you migrate at your own pace; add ingress to skipResourceTypes once the Gateway setup is validated to stop rendering the legacy Ingress.

See the Gateway API section of the dev deployment docs for setup instructions.

▶ [patch] #8526 Fixed the Azure provider's deprovisionResource wasting a worker-scanner cycle per resource when the backing VM/NIC/IP/disk had already been removed out-of-band (e.g. ARM cascade-delete via deleteOption: 'Delete', Spot preemption). Previously the pre-flight GET was skipped whenever the worker still had a stored id, so the scanner fired a no-op beginDelete first and only discovered the resource was gone on the following cycle. The helper now always performs the pre-flight GET, so a missing resource is marked deleted immediately and the reap chain continues in a single cycle, shortening the STOPPING tail for affected Azure pools.

▶ [patch] The default sendDeadline for the pulse publisher has been raised from 12 seconds to 30 seconds. Under load, RabbitMQ blocking and client reconnects could consume most of the 12-second budget before a single publish-confirm round-trip completed, causing cascading PulsePublisher.sendDeadline exceeded errors. The new default gives more headroom while still remaining below typical HTTP proxy timeouts. Services can override this per-publisher via the sendDeadline option to exchanges.publisher().

▶ [patch] bug 2028956 Worker Manager's Azure registration flow now restricts intermediate certificate downloads to trusted certificate distribution endpoints and records rejected certificate URLs in service logs.

WORKER-DEPLOYERS

▶ [patch] bug 2032277 worker-runner now tightens the permissions of its configuration file (typically runner.yml / worker-runner.json) to be readable only by its owner before reading it, and logs a warning if the file was previously group- or world-readable. This closes an exposure where a task running on a worker using the static provider could read the staticSecret out of a loosely-permissioned runner config and impersonate the worker via registerWorker. Worker deployers using the static provider should update their provisioning so the runner config is created with mode 0600 (or the equivalent owner-only ACL on Windows) from the start.

USERS

▶ [patch] #8534 Fix a 500 raised from hooks.triggerHook when a hook's task template evaluates to nothing. The endpoint now correctly replies with an empty object in that case.

... (truncated)

Changelog

Sourced from taskcluster's changelog.

v99.2.1

GENERAL

▶ [patch] #8525 Fix two related races that could leave a Taskcluster task in an inconsistent state when a Pulse publish failed during task creation or a run state transition:

• A run could transition to pending in tasks.runs without a corresponding queue_pending_tasks row, making the task invisible to workers and to the "pending tasks" UI/API counts. Transitions of a run to pending (schedule_task, rerun_task, resolve_task, check_task_claim) now commit the queue_pending_tasks row in the same database transaction as the tasks.runs update.
• A task could be inserted into tasks without a corresponding queue_task_deadlines row, leaving it untracked by the deadline resolver. createTask now inserts both rows atomically inside create_task_atomic.

In the queue's HTTP API handlers (createTask, scheduleTask, rerunTask, reportException), Pulse taskPending / taskException / taskDefined publishes that follow these now-atomic DB commits are best-effort: the database is the source of truth, so a Pulse publish failure no longer fails the operation. Consumers that need exact-once notification should treat Pulse as advisory and read queue.task(taskId).status for the authoritative state. Background resolvers (claim-resolver, worker-removed-resolver, dependency-resolver) preserve their pre-existing at-least-once publish semantics by continuing to fail the handler on Pulse error so redelivery re-attempts the publish.

USERS

▶ [patch] Update sha2 dependency in the rust client

OTHER

▶ Additional changes not described here: bug 2035431, #5457.

v99.2.0

DEPLOYERS

▶ [minor] #8243 Add optional Kubernetes Gateway API support (Gateway, HTTPRoute, HealthCheckPolicy) as an alternative to the existing Ingress resource. These new resources are only rendered when ingressType: gateway is set in Helm values, so existing Ingress-based deployments are unaffected and no new CRDs or skipResourceTypes entries are required.

To adopt Gateway API for traffic routing, set ingressType: gateway along with gatewayClassName, and for GKE regional external ALBs, gatewayStaticIpName and gcpManagedCertName. Both Ingress and Gateway API resources will be rendered side-by-side, letting you migrate at your own pace; add ingress to skipResourceTypes once the Gateway setup is validated to stop rendering the legacy Ingress.

See the Gateway API section of the dev deployment docs for setup instructions.

▶ [patch] #8526 Fixed the Azure provider's deprovisionResource wasting a worker-scanner cycle per resource when the backing VM/NIC/IP/disk had already been removed out-of-band (e.g. ARM cascade-delete via deleteOption: 'Delete', Spot preemption). Previously the pre-flight GET was skipped whenever the worker still had a stored id, so the scanner fired a no-op beginDelete first and only discovered the resource was gone on the following cycle. The helper now always performs the pre-flight GET, so a missing resource is marked deleted immediately and the reap chain continues in a single cycle, shortening the STOPPING tail for affected Azure pools.

▶ [patch] The default sendDeadline for the pulse publisher has been raised from 12 seconds to 30 seconds. Under load, RabbitMQ blocking and client reconnects could consume most of the 12-second budget before a single publish-confirm round-trip completed, causing cascading PulsePublisher.sendDeadline exceeded errors. The new default gives more headroom while still remaining below typical HTTP proxy timeouts. Services can override this per-publisher via the sendDeadline option to exchanges.publisher().

▶ [patch] bug 2028956 Worker Manager's Azure registration flow now restricts intermediate certificate downloads to trusted certificate distribution endpoints and records rejected certificate URLs in service logs.

WORKER-DEPLOYERS

▶ [patch] bug 2032277 worker-runner now tightens the permissions of its configuration file (typically runner.yml / worker-runner.json) to be readable only by its owner before reading it, and logs a warning if the file was previously group- or world-readable. This closes an exposure where a task running on a worker using the static provider could read the staticSecret out of a loosely-permissioned runner config and impersonate the worker via registerWorker. Worker deployers using the static provider should update their provisioning so the runner config is created with mode 0600 (or the equivalent owner-only ACL on Windows) from the start.

USERS

▶ [patch] #8534 Fix a 500 raised from hooks.triggerHook when a hook's task template evaluates

... (truncated)

Commits

• ddb9ce7 v99.2.1
• 5bb8f30 Merge pull request #8552 from Eijebong/fix-meta-generate-intermittent
• 5e72a85 Merge pull request #8551 from Eijebong/relax-go-version-check
• 87c0cd2 Merge pull request #8550 from Eijebong/update-sha2
• 422d673 Fix intermittent failures in meta-generate
• 32fbdf3 Relax the go version check a bit
• d4ec4b6 Merge pull request #8527 from taskcluster/matt-boris/pendingTasksAtomicity
• 558e6f9 Update sha2 to 0.11.0 in the rust client
• dc7b40d docs(queue): add changelog entry and update queue internals README
• d665f87 test(queue): pulse-failure regression test for reportException retry
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)