Repository navigation
Native: cap long polls and reserve HTTP capacity for health and admin (PHP 2.x parity) #982
Description
Found while documenting native 3.x configuration (docs#426, from rust/src/config_audit.rs at native-3.0.1 and current main). Native refuses or ignores every server-side capacity control PHP 2.x offered:
- Refused at startup: workflow-task/activity-task lease caps and dispatch caps (queue and namespace scope),
DW_TASK_QUEUE_ADMISSION_OVERRIDES, namespace request admission, namespace durable-state limits. - Ignored:
DW_WORKER_LONG_POLL_MAX_CONCURRENT,DW_QUERY_TASK_POLL_MAX_CONCURRENTand their per-namespace variants,DW_WORKER_LONG_POLL_RESERVED_HTTP_WORKERS. - Fixed: 4 database connections per process; 16 pending or leased query tasks per namespace (the full-queue status code is fixed by Answer a full query queue 429, as PHP does #975).
So operators who relied on these controls can't move to native (the takeover refuses them), and native has no server-side way to bound one namespace or queue against another. Capacity comes only from worker slots and worker counts.
Ask:
- Decide which controls native needs and which can stay PHP-only. Likely: per-queue lease/dispatch caps, namespace request admission and durable-state quotas, since Cloud and multi-team installs need them for fairness and cost bounds.
- Implement them with PHP-compatible variable names and semantics, through the parity fixtures. Each one moves from refused to honored in
config_audit.rs. - Until then,
native_unqualified/ cluster info should list them explicitly so operators see the gap (check whether it already does).
Priority: after 3.0.3 (#979 and its siblings). Cloud: say on this issue whether managed cells need any of these before admitting multi-tenant load.
Activity
rmcdaniel commentedon Nov 4, 2026
Server open-item pass, 2026-11-04.
General remains the product owner of admission scope; Server owns native enforcement. I mapped the overlapping existing items instead of creating a second quota project: #514 shared namespace/budget-group atomic dispatch, #577 runtime activity pause/zero semantics, #951 disk-pressure drain/fence, and #612 structural limits. Worker slot counts and aggregate metrics do not provide these Server admission guarantees.
General and Cloud: please enumerate the queue/namespace lease/dispatch/request/durable-state controls required before multi-tenant customer admission, including whether the current refused/ignored settings must remain refused until qualified. I will turn that decision into one bounded source/fixture slice at a time with typed refusal and no-debit/rollback controls. No startup setting is being reclassified as supported solely because native has a different co-located Runtime.
rmcdaniel commentedon Nov 4, 2026
Cloud source-contract input for broader native customer admission:
503 storage_pressureresponse/retry contract.These are dependencies for broader multi-tenant native load; final numeric limits depend on qualified resource headroom and the operation matrix, not invented default caps. Existing limited automation/qualification tenancy and refused settings remain. Physical HA/delivery acceptance also retains #526/#931: the frozen native 3.0.4→3.0.5 continuity tuple does not implement offer-accept.v1 and cannot claim that broader guarantee. No runtime, release, configuration or admission change follows this source input.
Named next owner: Server authors the operation matrix/shared vectors and implementation slices; Cloud supplies the pressure producer contract on #951 and reviews the resulting admission boundary with Security/General.
rmcdaniel commentedon Nov 13, 2026
Narrowed scope (server, 2026-11-13, General's call with Cloud's input)
Cloud's tenancy shape: a dedicated Server per customer. Each managed namespace runs in its own cell (Server + MySQL + Redis + tunnel), so cross-tenant fairness doesn't gate Cloud. What Cloud needs is for a cell to protect itself from its own customer's overload, so that Cloud's health/readiness probes and credential administration keep working.
This issue now covers only:
DW_WORKER_LONG_POLL_MAX_CONCURRENThonored, with PHP semantics. The per-namespace variants stay out of scope.DW_WORKER_LONG_POLL_RESERVED_HTTP_WORKERS(or the native equivalent) keeps health, readiness and admin routes served while polls hold the rest.DW_QUERY_TASK_POLL_MAX_CONCURRENT), but only if query polls aren't already bounded by (1). I'll check that when implementing.Durable-state / storage pressure is #951.
Closed as PHP-only and not needed for Cloud (multi-tenant fairness): per-queue lease caps, per-queue dispatch caps, namespace-scope lease/dispatch caps,
DW_TASK_QUEUE_ADMISSION_OVERRIDESand namespace request-rate admission. These settings stay refused at startup, as today (config_audit.rs). #514 was already closed on the same basis.Labels: kind:feature, P2. Next: implement (1)+(2) after #951. Owner: server.
[-]Native: restore server-side admission and quota controls (PHP 2.x parity)[/-][+]Native: cap long polls and reserve HTTP capacity for health and admin (PHP 2.x parity)[/+]rmcdaniel commentedon Nov 13, 2026
Cloud reconfirmed dedicated Server/customer namespace cells, so the narrowed scope above stands: global long-poll cap plus reserved health/readiness/admin capacity; query polls must join that same bound or receive their own explicit cap. This remains Server implementation work, queued after current combined3.9.1 correctness delivery and #951 follow-through, not a new product-decision blocker. Next source action traces every poll/claim path and places bounded admission before waits/DB ownership, with cancellation/disconnect/re-registration permit-release controls, authenticated diagnostics and an overload test proving health/admin reserve. Published unsupported settings remain refused/ignored as recorded until enforcement is implemented and qualified; no Cloud flip or fairness claim is made.