Skip to content

service: per-service budgets (rate, concurrency, tokens) are not enforced #1132

Description

@edwin-zvs

ServiceConfig has no budget field and nothing enforces one. A service accepts requests as fast as a channel delivers them, creating sessions and spending tokens without limit.

This matters more than the other gaps because service input is third-party by assumption. The design record already states the requirement — "budgets must be enforced per service so one noisy service cannot starve the fleet or the wallet" — and spec 0170 lists per-service budgets as explicitly not implemented while describing service sessions as least-privilege. Capability confinement shipped; resource confinement did not.

Scope to decide:

  • Rate — requests per interval per service, and whether per channel or aggregate.
  • Concurrency — simultaneous in-flight turns; the natural backstop against a webhook storm.
  • Tokens — per request, per session, or per window, and what happens at the ceiling (refuse, queue, degrade).

Rejections need to be visible to the caller (a distinct status, not a timeout) and to the operator. Note this interacts with #1133 — a budget you cannot observe being approached is hard to set correctly.

Per spec 0173's structural guarantee, any scalar added to ServiceConfig is read at use, so a budget field applies on the next request without additional plumbing.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions