[L4Ph]

Problem

When the active Worker version has any secret, void deploy --platform cloudflare uploads through the pinned-secret uploader instead of cf's. That uploader rebuilds every binding in bindingsFromOutput, which has no case for the worker-loader binding that cf emits for worker_loaders, so it reaches default and throws:

■ deploy: Cloudflare could not publish the Worker atomically (exit 1); inspect production status before retrying.

  Cloudflare binding LOADER cannot be uploaded with pinned secrets.

An app that uses Dynamic Workers (cloudflare: { worker_loaders: [{ binding: 'LOADER' }] }) and has any secret can't be deployed. I hit it with --atomic; reading the code, the non-atomic versions.upload path uses the same uploader whenever output.activeSecrets is set.

This is the same failure as #462 (ratelimits), for another binding type.

Fix

Map worker-loader to the worker_loader binding type in bindingsFromOutput. worker_loader is the Worker metadata binding type that Cloudflare's own packages use (@cloudflare/workers-utils).

Verification

• verifyPinnedUpload now declares worker_loaders and expects { name: 'LOADER', type: 'worker_loader' }. Without the source change both pinned-upload tests fail with the error above; with it, cf-version-runner.test.ts passes (127 tests). vp fmt --check and vp lint pass on the changed files, and packages/void typechecks.
• Deployed a real app that has worker_loaders and a required secret, using void 1.6.2 with this change (void deploy --platform cloudflare --atomic). The upload was accepted, and the live version lists LOADER: worker_loader next to the inherited secret (secret_text). Before the change, the same deploy stopped with the error above.
• Not covered: I did not exercise env.LOADER at runtime on that deployment. I only checked that the upload is accepted and the binding is present on the live version.

[cpojer]

👍