Repository navigation
Native: restore server-side admission and quota controls (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.