KB-12C0

110500x · 08 — Rollback Package

4 min read Revision 1
iu-core110500xrollback042Roperator-recovery

110500x · 08 — Rollback Package

The 042R apply is fully reversible. Three rollback options, in increasing scope:

Option A — Code-level rollback (drop alias fns + DOT rows)

Reverses ONLY the 042R additions. Leaves all 100000x pipeline functions intact.

BEGIN;
DROP FUNCTION IF EXISTS public.fn_iu_op_cleanup_dry_run(integer,text);
DROP FUNCTION IF EXISTS public.fn_iu_op_verify_cut(uuid,text);
DROP FUNCTION IF EXISTS public.fn_iu_op_cut(uuid,boolean,text,boolean);
DROP FUNCTION IF EXISTS public.fn_iu_op_verify_mark(uuid,boolean,text,text,text);
DROP FUNCTION IF EXISTS public.fn_iu_op_mark_file(text,text,jsonb,text,text,text,text,text);
DELETE FROM public.dot_iu_command_catalog
WHERE command_name IN (
  'dot_iu_operator_mark_file',
  'dot_iu_operator_verify_mark',
  'dot_iu_operator_cut_staging',
  'dot_iu_operator_verify_cut',
  'dot_iu_operator_cleanup_staging_dry_run'
);
COMMIT;

Expected delta:

  • public schema fns: 507 → 502
  • dot_iu_command_catalog: 41 → 36

Core pipeline (fn_iu_mark_create_manifest, fn_iu_verify_mark, fn_iu_cut_from_manifest, fn_iu_verify_cut_result, fn_iu_staging_cleanup) UNTOUCHED — they were not modified by 042R.

Option B — Restore pg_dump pre-110500x

If something contaminates state beyond 042R itself:

ssh contabo
# Stop directus so it doesn't write during restore
docker stop incomex-directus
# Restore (drop + recreate directus DB from dump)
docker exec postgres pg_restore -U postgres -d directus --clean --if-exists /tmp/pre-110500x.dump
docker start incomex-directus

/tmp/pre-110500x.dump:

  • in-container path: postgres:/tmp/pre-110500x.dump
  • host path (contabo): /tmp/pre-110500x.dump
  • size: 82,202,070 B
  • md5: 0591218ccb5ce3c4b93808139b27d35e

Option C — Operator-side bisect

If the live pipeline functions themselves get corrupted by an unrelated change:

  1. Restore from pre-100000x.dump (last known clean state for the 5-fn pipeline).
  2. Re-apply mig 037, 038, 039, 040R, 041R, 042R in order.

This is a fall-back not needed by 110500x itself — 042R is purely additive and reversible at the function/catalog level.

Validation post-rollback (for Option A)

SELECT count(*) FROM pg_proc p JOIN pg_namespace n ON n.oid=p.pronamespace
WHERE n.nspname='public' AND p.proname LIKE 'fn_iu_op_%';
-- expect 0

SELECT count(*) FROM dot_iu_command_catalog WHERE command_name LIKE 'dot_iu_operator_%';
-- expect 0

SELECT count(*) FROM dot_iu_command_catalog;  -- expect 36
SELECT count(*) FROM pg_proc p JOIN pg_namespace n ON n.oid=p.pronamespace
WHERE n.nspname='public';                      -- expect 502

When to roll back

  • A bug in the alias surface forces a hot fix and 042R is the cleanest line of return.
  • A pinning-test regression in cutter-agent CI cannot be satisfied without removing the new function names.
  • An unrelated production incident requires a narrow restore window.

None of these conditions present at 110500x exit. Rollback package is the safety belt, not the recommended path.

Operator carry-forward note

The matching cutter_agent/iu_core/dot_commands.py::_REGISTRY rows (5 entries) live in the application repo. If Option A is applied, also revert the repo commit that added those entries (or hold off merging it). Otherwise CI will fail with "DOT entry references missing fn".

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/v0.6-iu-core-110500x-apply-operator-alias-d30-d31-test/08-rollback-package.md