feat(#136): add operator endpoint to update tenant quotas#145
feat(#136): add operator endpoint to update tenant quotas#145dennisonbertram merged 2 commits intomainfrom
Conversation
Adds PATCH /v1/tenants/{tenantID}/quotas authenticated via bootstrap
token so operators can adjust per-tenant resource limits without
direct DB access. Supports partial updates (only non-nil fields are
written), validates positive values within hard caps (services=100,
databases=50, builds=10, env_vars=500), and logs all changes at
AUDIT level.
Includes migration state_014 adding max_builds_concurrent and
max_env_vars_per_service columns to tenant_quotas.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ffeed365ae
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| setClauses = append(setClauses, "max_builds_concurrent = ?") | ||
| args = append(args, *req.MaxBuildsConcurrent) |
There was a problem hiding this comment.
This handler accepts and stores max_builds_concurrent, but the runtime build path never consults tenant quotas: internal/builder/builder.go still uses fixed concurrency (buildSem capacity 3) and a hard per-tenant single-build gate in acquireTenant (return false if one build is active). That means operators can PATCH this field successfully yet tenant build concurrency behavior does not change, so the new quota is effectively non-functional.
Useful? React with 👍 / 👎.
| setClauses = append(setClauses, "max_env_vars_per_service = ?") | ||
| args = append(args, *req.MaxEnvVarsPerService) |
There was a problem hiding this comment.
The endpoint persists max_env_vars_per_service, but env-var mutation paths still use static validation and do not read tenant quotas (for example, internal/api/services.go hard-caps len(vars) at 100, and internal/services/services.go validation checks key/value format only). In practice, a tenant can be configured to a lower env-var quota via this PATCH and still set more vars than allowed, so the new quota field is not actually enforced.
Useful? React with 👍 / 👎.
1 participant
Summary
PATCH /v1/tenants/{tenantID}/quotasauthenticated via bootstrap tokenmax_services,max_databases,max_builds_concurrent,max_env_vars_per_servicestate_014_quota_columns.sqladdsmax_builds_concurrentandmax_env_vars_per_servicecolumnsCloses #136
Test plan
go build ./...passesgo test ./...passes (pre-existing flaky test unrelated)🤖 Generated with Claude Code