fix(catalog): correct stale Mokosh app names and disable vervain-agent (BUNYIP-374) #371

Merged

nrupard merged 1 commit from fix/BUNYIP-374-applications-catalog-names-vervain into main

2026-07-15 23:00:46 +02:00

nrupard commented

2026-07-15 22:25:27 +02:00

Owner

Fixes BUNYIP-374. This is the root-cause fix for PMS-667 (the stale mokosh-server applications list); traced there, the source is entirely bunyip.

Context

The hub admin "Applications" page is backed by bunyip's applications catalog, seeded by migrations/20260602000050_seed_distribution_catalog.sql with canonical "Mokosh" names and is_active = TRUE, via INSERT ... ON CONFLICT (slug) DO NOTHING. Staging still shows the old Mokash / mokash display names and an active Vervain Agent. Those old strings are not in any source (migrations, seed JSON, and git history all say "Mokosh"; git log -i -S "Mokash" is empty) - they are live rows in staging's DB from an out-of-band seed or a manual admin edit, and the seed's DO NOTHING can never correct them. mokosh-server does not produce this list.

Change

migrations/20260715000010_fix_applications_catalog_names_and_vervain.sql - a one-time correction:

UPDATE applications SET display_name = 'Mokosh Server' / 'Mokosh API' / 'Mokosh Web' for the mokosh slugs, scoped AND display_name <> '<canonical>' so already-correct / fresh rows are untouched and only the stale ones are rewritten.
UPDATE applications SET is_active = FALSE WHERE slug = 'vervain-agent'.

On a fresh DB it runs after the seed, so the name updates are a no-op and vervain-agent is simply disabled. On staging it corrects the stale rows. vervain-agent is disabled everywhere by default (PMS-667 decision); a deployment enables it in the admin UI when it ships, and that enable persists because the migration runs once.

tests/applications_catalog.rs asserts the post-migration catalog: mokosh apps have the canonical "Mokosh" names, no "Mokash" survives, and vervain-agent is inactive. Env-gated like rls_isolation.rs (needs BUNYIP_TEST_DATABASE_URL / RLS_TEST_DATABASE_URL; skips otherwise).

Verification

Applied the migration to a throwaway Postgres seeded with staging-like stale rows (Mokash Server / Mokash API / mokash www, active vervain-agent, plus an unrelated drillmark): names corrected to canonical, vervain-agent flipped to inactive, the unrelated app untouched.
just check-container green: fmt + clippy + cargo test --workspace --all-targets (the new test compiles and runs; it skips without a test-DB env var, matching the repo's existing integration-test posture).

Fixes BUNYIP-374. This is the root-cause fix for PMS-667 (the stale mokosh-server applications list); traced there, the source is entirely bunyip. ## Context The hub admin "Applications" page is backed by bunyip's `applications` catalog, seeded by `migrations/20260602000050_seed_distribution_catalog.sql` with canonical "Mokosh" names and `is_active = TRUE`, via `INSERT ... ON CONFLICT (slug) DO NOTHING`. Staging still shows the old `Mokash` / `mokash` display names and an active `Vervain Agent`. Those old strings are not in any source (migrations, seed JSON, and git history all say "Mokosh"; `git log -i -S "Mokash"` is empty) - they are live rows in staging's DB from an out-of-band seed or a manual admin edit, and the seed's `DO NOTHING` can never correct them. mokosh-server does not produce this list. ## Change `migrations/20260715000010_fix_applications_catalog_names_and_vervain.sql` - a one-time correction: - `UPDATE applications SET display_name = 'Mokosh Server' / 'Mokosh API' / 'Mokosh Web'` for the mokosh slugs, scoped `AND display_name <> '<canonical>'` so already-correct / fresh rows are untouched and only the stale ones are rewritten. - `UPDATE applications SET is_active = FALSE WHERE slug = 'vervain-agent'`. On a fresh DB it runs after the seed, so the name updates are a no-op and vervain-agent is simply disabled. On staging it corrects the stale rows. vervain-agent is disabled everywhere by default (PMS-667 decision); a deployment enables it in the admin UI when it ships, and that enable persists because the migration runs once. `tests/applications_catalog.rs` asserts the post-migration catalog: mokosh apps have the canonical "Mokosh" names, no "Mokash" survives, and vervain-agent is inactive. Env-gated like `rls_isolation.rs` (needs `BUNYIP_TEST_DATABASE_URL` / `RLS_TEST_DATABASE_URL`; skips otherwise). ## Verification - Applied the migration to a throwaway Postgres seeded with staging-like stale rows (`Mokash Server` / `Mokash API` / `mokash www`, active vervain-agent, plus an unrelated `drillmark`): names corrected to canonical, vervain-agent flipped to inactive, the unrelated app untouched. - `just check-container` green: fmt + clippy + `cargo test --workspace --all-targets` (the new test compiles and runs; it skips without a test-DB env var, matching the repo's existing integration-test posture).

nrupard added 1 commit

2026-07-15 22:25:27 +02:00

fix(catalog): correct stale Mokosh app names and disable vervain-agent

E2E / Playwright against deployment (pull_request) Successful in 44s

Details

Check / fmt + clippy + build + tests (pull_request) Successful in 35m17s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

760905c788

Root-cause fix for PMS-667 (the stale mokosh-server applications list). Traced there, the list is bunyip's `applications` catalog, not mokosh-server: the seed (20260602000050) already uses canonical "Mokosh" names and is_active=TRUE via ON CONFLICT DO NOTHING, so it can never correct rows that already exist. Staging's long-lived DB still carries the old `Mokash`/`mokash` display names (from an out-of-band seed or manual admin edit; not in any source) and an active vervain-agent.

Add a one-time correction migration: rewrite the mokosh-server/mokosh-api/mokosh-www display names to canonical (scoped to non-canonical rows, so fresh/correct rows are untouched) and set vervain-agent is_active=FALSE. On a fresh DB it runs after the seed, so the name updates are a no-op and vervain-agent is disabled; on staging it corrects the stale rows. vervain-agent ships disabled everywhere by default (PMS-667 decision); a deployment enables it in the admin UI when ready, and that enable persists because the migration runs once.

tests/applications_catalog.rs asserts the post-migration catalog (canonical names, no `Mokash`, vervain inactive), env-gated like rls_isolation.rs.

Verified: applied to a throwaway Postgres seeded with staging-like stale rows - names corrected, vervain disabled, an unrelated app untouched; `just check-container` green.

#BUNYIP-374
#PMS-667

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

nrupard scheduled this pull request to auto merge when all checks succeed

2026-07-15 22:30:34 +02:00