Skip to content

ref(hybridcloud): Register webhook worker threads at the deployed value - #123716

Open
vaind wants to merge 2 commits into
masterfrom
ivandlugos/baseline-webhook-worker-threads
Open

ref(hybridcloud): Register webhook worker threads at the deployed value#123716
vaind wants to merge 2 commits into
masterfrom
ivandlugos/baseline-webhook-worker-threads

Conversation

@vaind

@vaind vaind commented Sep 7, 2026

Copy link
Copy Markdown
Contributor

hybridcloud.webhookpayload.worker_threads caps how many threads a webhook drain delivers on. The code registers 4; every deployed environment has run 16 since automator#928 in March 2024. This registers 16.

Production is unchanged — the automator value wins, and it is the value being registered. What the mismatch cost: defaults.py named a concurrency nobody runs, and the automator entry could not be dropped while 4 was the fallback, since unsetting it would quarter delivery concurrency with no code change.

An environment with no automator entry — self-hosted, or a region that never got one — goes from 4 threads to 16. A drain uses min(worker_threads, records claimed) threads, and only for skip-on-failure providers; strict providers deliver on one thread regardless.

The option stays registered: thread count is a real knob, and #123449 makes it load-bearing in mailbox sizing. Next is the automator dropping four now-redundant entries, all holding 16, once this has deployed everywhere.

Verification: tests/sentry/hybridcloud/tasks/test_deliver_webhooks.py 147 passed, prek run -q clean.

Fixes CW-1827

The automator has set `hybridcloud.webhookpayload.worker_threads` to 16 for
every environment since #928 in March 2024, so the registered 4 has not been
the number any deploy runs for over two years. Reading the registration told
you the wrong thing, and the value cannot be dropped from the automator while
the two disagree — unsetting it would quietly quarter the delivery
concurrency.

Production is unchanged: the automator value wins and is identical. An
environment with no automator entry, self-hosted included, moves from 4 to 16,
bounded by the records a claim actually holds and only for skip-on-failure
providers; strict providers keep delivering on one thread.
@vaind
vaind requested a review from a team as a code owner September 7, 2026 06:59
@linear-code

linear-code Bot commented Sep 7, 2026

Copy link
Copy Markdown

CW-1827

@github-actions github-actions Bot added the Scope: Backend Automatically applied to PRs that change backend components label Sep 7, 2026
@vaind
vaind requested a review from joseph-sentry September 7, 2026 07:15
The line about strict providers repeated what the skip_on_failure_providers
comment two registrations below already says.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Backend Automatically applied to PRs that change backend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant