## Summary Tracking issue for all breaking schema and code changes that must land during the maintenance window before Open Beta. These changes are safe because close beta data will be truncated. Parent issue: #599338 Related: #596409 ## Tasks ### Critical: Deprovision flow correctness (from !235208 review) - [x] **Fix project transfer + delete deprovisioning with new computed paths** — Landed in !236024. `InitiateDeprovisionService` now takes required snapshot kwargs (`organization_id`, `root_namespace_id`, `parent_group_id`); each hook captures the IDs *before* `super` and threads them in. The async `DeprovisionService` reads paths from the maintenance task (`MaintenanceTaskPathResolver`) instead of live `secrets_manager.project.X` associations. Group destroy/transfer hooks follow the same pattern. Adds real integration coverage in transfer/destroy specs. ### Provisioning flow correctness - [ ] **Move provisioning to the maintenance task pattern** — Tracked in #600342. Provisioning today is fire-and-forget against Sidekiq's own retry budget. If a worker exhausts retries (Sidekiq OOM, worker death, persistent OpenBao timeout), the SM is stuck in `provisioning` forever with no in-product recovery and no stale tracking. Mirror the deprovision flow: insert a `provision`-action maintenance task at `InitializeService` time, worker takes the task id, cron retry picks up stale tasks. Should land before Open Beta adoption grows to avoid support-team intervention. ### Schema cleanup - [ ] ~~**SM tables: NOT NULL ON DELETE CASCADE**~~ — **Design pivot in !236024.** Keep `project_id`/`group_id` nullable with `ON DELETE SET NULL`. The orphan reaper (#600120) uses the surviving SM row (`where(parent_id: nil)`) as its work signal; CASCADE would destroy the rows the reaper relies on. Code comments on both SM models explicitly ask future contributors NOT to flip to CASCADE. - [ ] **Drop org_id trigger on project maintenance tasks** — Trigger `trigger_project_secrets_manager_maintenance_tasks_organization_` (function `project_secrets_manager_maintenance_tasks_organization_id()`) is still present in `db/structure.sql`. !236024 now passes `organization_id` explicitly in Ruby for every insert path (instance and bulk), so the trigger is unused. Drop the trigger and the function. - [ ] **Decide whether `parent_group_id` on `project_secrets_manager_maintenance_tasks` stays** — !236024 keeps it (validated presence on the model, written by both `InitiateDeprovisionService` and `bulk_initiate_for_projects`) but the 3-level OpenBao path scheme `org_<X>/group_<R>/project_<P>` doesn't reference it; level 2 uses `root_namespace_id`. Decide: drop it for being denormalised-and-unused, or keep it as a stable handle for the immediate parent group (useful for audit, reaper diagnostics). - [ ] ~~**Maintenance task tables rework (decouple from SM records)**~~ — **Direction reversed in !236024 + #600290.** Original intent was to drop `secrets_manager_id` from task tables and have the worker re-derive everything from loose IDs. Actual design keeps the FK link: project tasks already have `project_secrets_manager_id ON DELETE CASCADE`, and #600290 will add the symmetric `group_secrets_manager_id` to group tasks. Task path methods continue to delegate to SM class methods via `MaintenanceTaskPathResolver`, which was the useful half of the original task. ### Legacy code removal - [x] **Remove legacy (non-CEL) pipeline JWT auth** — Done (!235208 / earlier). ### Spec coverage updates - [ ] **Update AuditLog spec fixtures for 3-level paths** — The audit log regex patterns in `ee/app/models/secrets_management/audit_log.rb` are compatible with the new scheme (don't depend on path prefix), but the spec fixtures still use old-format paths (`group_<R>/group_<R>/`). Update fixtures to use new-format paths (`org_<X>/group_<R>/group_<R>/`) for realistic test coverage. Note: subgroup audit logs (`org_X/group_R/group_S/` where R≠S) won't match `namespace_path_matches_group_path?` — pre-existing limitation, not a regression. ### Cached path columns (decision update from !236024) - [x] ~~**Remove `ignore_column` calls**~~ — **Design pivot in !236024.** `ignore_column` directives are *removed*, and `before_create :set_cached_paths` callbacks now populate `namespace_path` / `project_path` (project SM) and `root_namespace_path` / `group_path` (group SM) at create time with the 3-level format (`org_<X>/group_<R>` prefix + entity segment). These columns are the orphan reaper's recovery signal for destroyed SMs whose maintenance task was never created. Drop migrations for the columns are NOT planned; they stay as load-bearing cached data. ## Follow-ups opened during !236024 These issues track work that was either intentionally deferred to keep !236024 reviewable, or surfaced during !236024's review and smoke testing: - #600120 — **Orphan OpenBao namespace reaper worker.** Sweeps destroyed orphans (`where(parent_id: nil)`) and transferred orphans (path divergence between cached and live path) and tears down the abandoned OpenBao state. Includes the SQL detection plan and state-machine handling per state. - ~~#600129~~ — **Perf follow-up for the transfer subtree walk.** Closed; obsoleted by !236024's batched bulk-insert transfer flow. - #600250 — **Misleading "already exists" error during async deprovision window.** Once a deprovision is initiated the SM row sits in `deprovisioning` state until the async worker destroys it. During that window any re-enroll attempt fails with a generic uniqueness violation. Fix in `InitializeService` (project + group) to detect the deprovisioning state and return a clear "cleanup in progress, try again shortly" message. - #600290 — **Add `group_secrets_manager_id` FK to group maintenance task table.** Mirrors the project task FK, removes the path-based fallback that !236024 added for the group destroy flow. This is the FK side of the "Maintenance task tables rework" task above. - #600342 — **Move provisioning to maintenance task pattern.** Cross-listed under "Provisioning flow correctness" above. Adds retry + stale tracking that the provision path is missing today. ## Context These changes are only safe during the maintenance window when close beta data is truncated. After Open Beta, these would require migrations and backward compatibility logic. This is our last opportunity to make breaking changes cheaply.