ci(handlers-postgres): widen required-tables guard to include workspace_auth_tokens + org_api_tokens (#2148) #2449
Reference in New Issue
Block a user
Delete Branch "fix/handlers-pg-required-tables-widen"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What
Widen the post-migration table-presence guard in
.gitea/workflows/handlers-postgres-integration.ymlto include the two auth tables required by the registry-authTestIntegration_suite (WIP #2156 / issue #2148):workspace_auth_tokens(migration 020)org_api_tokens(migration 035)The current list covers
delegations / workspaces / activity_logs / pending_uploads / workspace_schedules. The auth tables were missing from the guard, so a silently-skipped migration 020 or 035 (the surrounding apply-all-or-skip loop suppresses migration failures) would let the auth tests run against missing tables and falsely green.Why this is cleanly-separable
This is the CR2 action item flagged in the #2156 WIP body:
The WIP test code (#2156) remains the devops-engineer / dispatched-agent lane; this PR closes the guard gap independently and can be reviewed + merged on its own. It also unblocks the #2156 suite's full coverage (with the guard in place, the auth tests' table-missing failure mode surfaces as a real CI failure rather than a false green).
Test plan
.gitea/workflows/handlers-postgres-integration.ymlparses; only the loop body changed).Handlers Postgres Integrationjob: green (both auth tables should be present after the standard apply-all-or-skip migration replay on the sibling Postgres).workspace_auth_tokensororg_api_tokensmigrations, the guard now surfaces it as::error::instead of silently skipping the auth tests.Watch-fail intent (regression-first)
workspace_auth_tokenstable missing → guard hard-fails the integration job.org_api_tokens.References
APPROVED on current head
d1bcc09aa0.QA/gate review: required branch-protection contexts are green (CI/all-required, E2E API Smoke Test, Handlers Postgres Integration) and trusted sop-checklist is green. The change is a single workflow-scope guard strengthening the Handlers PG post-migration required-table check: it adds workspace_auth_tokens and org_api_tokens to the existing hard-fail loop, so missing migration 020 or 035 tables fail the job instead of allowing a falsely green run. The loop uses a fixed table allowlist, not PR/user input, so the table-presence SQL remains bounded to deterministic schema checks.
Content-security assessment: the added schema table names and migration numbers are repo migration identifiers needed to explain the guard; I found no credentials, token values, provisioning mechanics, ACL-routing details, hostnames, or sensitive runtime internals. Scope matches the PR body and does not touch the WIP test code. No regression or gate weakening found.
Security-team-21 review on current head
d1bcc09a. This is a gate-strengthening change: the Handlers Postgres post-migration table guard now includes workspace_auth_tokens (migration 020) and org_api_tokens (migration 035), so missing auth tables hard-fail instead of allowing a falsely green handlers integration run. Required contexts are present+green: CI/all-required, E2E API Smoke, Handlers Postgres, trusted SOP; Local Provision is advisory. No qa/security/sop/required-CI weakening found. Content-security clean: table names and migration numbers are repo-local schema identifiers, not secrets/credentials/provisioning mechanics.Security-team-21 review on current head
d1bcc09a. This is a gate-strengthening change: the Handlers Postgres post-migration table guard now includes workspace_auth_tokens (migration 020) and org_api_tokens (migration 035), so missing auth tables hard-fail instead of allowing a falsely green handlers integration run. Required contexts are present+green: CI/all-required, E2E API Smoke, Handlers Postgres, trusted SOP; Local Provision is advisory. No qa/security/sop/required-CI weakening found. Content-security clean: table names and migration numbers are repo-local schema identifiers, not secrets/credentials/provisioning mechanics.