MQ-1242: Removing a consumer from Wrangler config should detach that consumer#13923
Conversation
`wrangler deploy` now sends the full list of declared queue consumers to a single script-level EWC endpoint, removing stale consumer registrations when a consumer is removed from the config. The per-consumer outcome (created/updated/removed/failed) is reported inline with the rest of the trigger summary. If a consumer fails to configure, the error is printed and the deploy exits with a non-zero status without aborting other trigger deployments.
…ndpoint Updates queue consumer deployment tests to use `mockSetScriptConsumers` instead of individual `mockPostConsumerById` and `mockPutQueueConsumerById` mocks, reflecting the new script-level queue consumer configuration endpoint. Adds test coverage for multiple consumers in a single request and updates assertions to match the new API response format.
🦋 Changeset detectedLatest commit: bcc51d8 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
workers-devprod
requested review from
a team and
jamesopstad
and removed request for
a team
|
Codeowners approval required for this PR:
Show detailed file reviewers
|
tgarg-cf
changed the title
create-cloudflare
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
commit: |
| } | ||
| // Always call so stale consumers from previous deploys are cleaned up, | ||
| // even when the user has removed all consumers from their config. | ||
| deployments.push(updateQueueConsumers(scriptName, config, queueNameToId)); |
There was a problem hiding this comment.
Context: we want consumers to be cleaned up even if the user has removed the queues section from the wrangler.jsonc.
| const targets = await Promise.all(deployments); | ||
| const deployMs = Date.now() - start - uploadMs; | ||
|
|
||
| if (deployments.length > 0) { |
There was a problem hiding this comment.
Since we are now calling updateQueueConsumers() on every deploy, this check is no longer accurate. Comparing with the flat targets instead
| Removed consumer for old-queue | ||
| ``` | ||
|
|
||
| If a consumer fails to configure, the error is printed both inline and to stderr, and the deploy exits with a non-zero status without aborting other trigger deployments. |
There was a problem hiding this comment.
So you are saying that the Worker deployment will complete (along with other triggers) but that Wrangler will exit with non-zero status, indicating that it actually failed?
There was a problem hiding this comment.
But if the wrangler team prefers a different behaviour, we are okay with that. I was trying to find the least invasive approach.
| logger.error(`Failed to configure queue consumers: ${message}`); | ||
| process.exitCode = 1; |
There was a problem hiding this comment.
Using process.exitCode is a bit awkward. E.g. what does 1 mean? It may be more work but I think if we really want deploy to soft-fail then we should provide a way for the deploy handler to capture a FatalError thrown from this function and continue with the rest of the deployment before "failing" at the end.
There was a problem hiding this comment.
That does sound better. Could you give me more direction on what that would look like? We call this function in triggersDeploy (https://github.com/cloudflare/workers-sdk/blob/main/packages/wrangler/src/triggers/deploy.ts#L263) and the promises are resolved in https://github.com/cloudflare/workers-sdk/blob/main/packages/wrangler/src/triggers/deploy.ts#L306. What should the handler do if it receives an error?
3 participants
Fixes https://jira.cfdata.org/browse/MQ-1242
Describe your change...
wrangler deploynow cleans up stale queue consumer registrations.Previously, when a user removed a queue consumer from their
wrangler.jsonconfig and redeployed, Wrangler left the old consumer registration in place — the worker continued receiving messages from a queue it no longer declared. This was because deploy only ever called the create/update consumer endpoints for the consumers currently in the config list.This PR replaces the per-consumer create/update calls with a single declarative call to EWC's new script-level endpoint (
PUT /accounts/{accountId}/workers/scripts/{scriptName}/queue-consumers). Wrangler sends the full, authoritative list of declared consumers, and EWC creates, updates, or deletes registrations as needed.The endpoint is called on every deploy (not just when consumers are declared) so stale registrations get cleaned up even if the user removes the entire
queuessection. This has to be done as wrangler doesn't track diffs between deploys but the cost for non-queue workers is a cheap no-op call to EWC per deploy.A picture of a cute animal (not mandatory, but encouraged)