fix(ci): bump Wrangler lower bound to ^4.81.0, pin all deno task wrangler* entries, use deno task wrangler in deploy step

[Copilot]

Cloudflare deployments have been failing deterministically on every push to main. Wrangler 4.77–4.80 has a known regression where deploying a worker with a [[containers]] binding causes a broken internal fetch call during the container image upload phase — fetch failed every time, not transient.

Description

Three related changes ensure the ^4.81.0 version bound is enforced consistently across every Wrangler invocation in the repo.

Changes

• deno.json (import map) — Raise Wrangler import-map lower bound from ^4.77.0 → ^4.81.0 to match the version already resolved in deno.lock (4.81.0) and prevent the broken range from being re-resolved on lockfile regeneration.

• deno.json (tasks) — Pin all 15 deno task wrangler* task definitions from the unversioned npm:wrangler to npm:wrangler@^4.81.0 so every task invocation uses the same version bound as the import-map alias, making the CI fix deterministic.

• .github/actions/deploy-worker/action.yml — Replace the bare deno run -A npm:wrangler invocation in the Deploy Worker step with deno task wrangler, so the deploy step honours the import map and deno.lock consistently with every other Wrangler call in the project.

# deno.json — import map
-"wrangler": "npm:wrangler@^4.77.0",
+"wrangler": "npm:wrangler@^4.81.0",

# deno.json — tasks (all 15 wrangler* entries, e.g.)
-"wrangler": "deno run -A npm:wrangler",
+"wrangler": "deno run -A npm:wrangler@^4.81.0",

# .github/actions/deploy-worker/action.yml
-deno run -A npm:wrangler deploy --var SENTRY_RELEASE:${{ inputs.github-sha }}
+deno task wrangler deploy --var SENTRY_RELEASE:${{ inputs.github-sha }}

deno.lock is not modified — it already resolves to 4.81.0.

Testing

• Unit tests added/updated
• Manual testing performed — verified all changed files contain the correct values post-edit
• CI passes

Zero Trust Architecture Checklist

This PR does not touch worker/ or frontend/.

Worker / Backend

• Every handler verifies auth before executing business logic — N/A
• CORS origin allowlist enforced (not *) on write/authenticated endpoints — N/A
• All secrets accessed via Worker Secret bindings (not [vars]) — N/A
• All external inputs Zod-validated before use — N/A
• All D1 queries use parameterized .prepare().bind() (no string interpolation) — N/A
• Security events emitted to Analytics Engine on auth failures — N/A

Frontend / Angular

• Protected routes have functional CanActivateFn auth guards — N/A
• Auth tokens managed via Clerk SDK (not localStorage) — N/A
• HTTP interceptor attaches ****** (no manual token passing) — N/A
• API responses validated with Zod schemas before consumption — N/A

API Shield / Vulnerability Scanner

This PR does not touch openapi.yaml or resource handlers.

• New/changed endpoints have a unique operationId in openapi.yaml — N/A
• Resource endpoints (those with /{id} path parameters) include a security: annotation — N/A
• Resource queries are scoped to the authenticated user (WHERE user_id = ?) — N/A
• Missing/unauthorized resources return 404 (not 403) to avoid leaking resource existence — N/A
• cloudflare-schema.yaml regenerated if openapi.yaml changed (deno task schema:cloudflare) — N/A

---

If this PR does not touch worker/ or frontend/, the ZTA checklist is not required.
If this PR does not touch openapi.yaml or resource handlers, the API Shield checklist is not required.

Original prompt

Problem

Cloudflare deployments have been failing on every push to main for several days. The CI run at https://github.com/jaypatrick/adblock-compiler/actions/runs/24287822198/job/70920282396 (and the prior run 24287474259) shows the same deterministic failure:

▲ [WARNING] A fetch request failed, likely due to a connectivity issue.
✘ [ERROR] fetch failed
Note that there is a newer version of Wrangler available (4.81.1).

This fetch failed occurs every single attempt, both for the tail worker deploy and the main worker deploy. It is not transient — it is a known regression in Wrangler 4.77–4.80 where deploying a worker with a [[containers]] binding causes a broken internal fetch call during the container image upload phase.

Root Causes

1. deno.json Wrangler specifier has a stale lower bound

In deno.json line 118:

"wrangler": "npm:wrangler@^4.77.0",

The deno.lock has already resolved this to 4.81.0:

"npm:wrangler@^4.77.0": "4.81.0_@cloudflare+workers-types@4.20260317.1",

But because the lower bound is ^4.77.0, the import map specifier is misleading and could resolve to a broken version if the lockfile is regenerated or updated. The specifier should be updated to ^4.81.0 to match the locked version and prevent regression.

2. The Deploy Worker step in action.yml bypasses the lockfile

In .github/actions/deploy-worker/action.yml line 164:

deno run -A npm:wrangler deploy --var SENTRY_RELEASE:${{ inputs.github-sha }}

This invokes npm:wrangler directly via deno run, bypassing deno.json's import map and deno.lock. This means it may resolve to a different Wrangler version than what all the deno task wrangler calls use elsewhere. It should use deno task wrangler for consistency.

Required Changes

Change 1: deno.json

Update line 118 from:

"wrangler": "npm:wrangler@^4.77.0",

to:

"wrangler": "npm:wrangler@^4.81.0",

Change 2: .github/actions/deploy-worker/action.yml

In the Deploy Worker step (around line 164), change the run command from:

echo "Deploying version: ${{ steps.version.outputs.full_version }}"
deno run -A npm:wrangler deploy --var SENTRY_RELEASE:${{ inputs.github-sha }}

to:

echo "Deploying version: ${{ steps.version.outputs.full_version }}"
deno task wrangler deploy --var SENTRY_RELEASE:${{ inputs.github-sha }}

Notes

• Do NOT modify deno.lock — the lock file already has the correct resolved version (4.81.0). Only deno.json's specifier string needs updating.
• Only these two files need to change.
• Make no other modifications.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Cloudflare deployments are failing https://github.com/jaypatrick/adblock-compiler/actions/runs/24287822198/job/70920282396

Assistant: Now let me look at the workflow and wrangler config to understand the full picture:

Assistant: Here's the root cause analysis of the failing deployment:

Root Cause: Tail Worker fetch failed → Main Worker Deploy Aborted

The failure is not a code bug — it's a Wrangler networking/connectivity error occurring during the tail worker (adblock-tail) deploy step, which then cascades to the main worker deploy.

What's happening

Looking at the log sequence:

1. Tail worker deploy fails 3 times with fetch failed — Wrangler's HTTP client cannot reach api.cloudflare.com during the upload phase. This is a transient Cloudflare API connectivity issue from the GitHub Actions runner.

2. The tail worker failure is non-fatal (correctly marked ::warning:: and continues).

3. Main worker deploy then also fails with the same fetch failed error at the wrangler deploy step (step Deploy Worker, line deno run -A npm:wrangler deploy).

▲ [WARNING] A fetch request failed, likely due to a connectivity issue.
  Please check your network connection and try again.
✘ [ERROR] fetch failed
Note that there is a newer version of Wrangler available (4.81.1).

4. The record-deployment.ts script records it as status=failed.

Two real issues found

Issue 1 — Wrangler version is outdated:
Wrangler is printing Note that there is a newer version of Wrangler available (4.81.1). The version currently used may have a known connectivity bug that was fixed in a newer release.

Issue 2 — Main worker deploy has no retry logic, unlike the tail worker. The tail worker has a 3-attempt retry loop, but the Deploy Worker step in action.yml line 164 is a single bare invocation:

        - name: Deploy W...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

*This pull request was created from Copilot chat.*
>

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	eslint@​10.0.3

View full report

[socket-security]

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Action	Severity	Alert  (click "▶" to expand/collapse)
Warn		License policy violation: npm dijkstrajs License: HPND-sell-MIT-disclaimer-xserver - The applicable license policy does not permit this license (5) (package/LICENSE.md) From: pnpm-lock.yaml → npm/dijkstrajs@1.0.3 ℹ Read more on: This package | This alert | What is a license policy violation? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Find a package that does not violate your license policy or adjust your policy to allow this package's license. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/dijkstrajs@1.0.3. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Obfuscated code: npm entities is 91.0% likely obfuscated Confidence: 0.91 Location: Package overview From: pnpm-lock.yaml → npm/@angular-devkit/build-angular@21.2.2 → npm/entities@4.5.0 ℹ Read more on: This package | This alert | What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/entities@4.5.0. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.
Warn		Obfuscated code: npm entities is 91.0% likely obfuscated Confidence: 0.91 Location: Package overview From: pnpm-lock.yaml → npm/entities@6.0.1 ℹ Read more on: This package | This alert | What is obfuscated code? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Packages should not obfuscate their code. Consider not using packages with obfuscated code. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore npm/entities@6.0.1. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.

View full report

[Copilot]

Pull request overview

Adjusts the CI deployment tooling to avoid a known broken Wrangler range and to make GitHub Actions deployments use the same Wrangler invocation approach as the rest of the repo.

Changes:

• Bumps the Wrangler import-map lower bound in deno.json from ^4.77.0 to ^4.81.0.
• Updates the composite deploy action to run the worker deploy via deno task wrangler ... instead of a direct deno run -A npm:wrangler ... invocation.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
deno.json	Raises the Wrangler import-map minimum version to avoid the regressed versions.
.github/actions/deploy-worker/action.yml	Makes the main deploy step use the repo’s standard deno task wrangler entrypoint.

[jaypatrick]

@copilot apply changes based on the comments in this thread

[Copilot]

@copilot apply changes based on the comments in this thread

Done in fe6bb15. All 15 deno task wrangler* definitions in deno.json (lines 78–92) have been updated from npm:wrangler to npm:wrangler@^4.81.0, so the version bound is now enforced consistently across every Wrangler invocation — tasks, the deploy action step, and the import-map alias all reference ^4.81.0.