From c0f397b8d28298821b29a3f44daefc99c2aceaee Mon Sep 17 00:00:00 2001 From: Multica Eve Date: Tue, 28 Jul 2026 18:36:38 +0800 Subject: [PATCH] fix(migrations): remove historical skill-bundle backfill (MUL-5400) (#6045) * fix(migrations): skip historical skill bundle backfill (MUL-5400) Co-authored-by: multica-agent * fix(migrations): drop unused skill bundle migration Co-authored-by: multica-agent --------- Co-authored-by: Eve Co-authored-by: multica-agent --- ...backfill_skill_bundle_unavailable.down.sql | 16 --------- ...3_backfill_skill_bundle_unavailable.up.sql | 33 ------------------- 2 files changed, 49 deletions(-) delete mode 100644 server/migrations/233_backfill_skill_bundle_unavailable.down.sql delete mode 100644 server/migrations/233_backfill_skill_bundle_unavailable.up.sql diff --git a/server/migrations/233_backfill_skill_bundle_unavailable.down.sql b/server/migrations/233_backfill_skill_bundle_unavailable.down.sql deleted file mode 100644 index 747345ae58..0000000000 --- a/server/migrations/233_backfill_skill_bundle_unavailable.down.sql +++ /dev/null @@ -1,16 +0,0 @@ --- Reverse the backfill: return the re-classified rows to agent_error.unknown, --- the single bucket the up migration took them from. Restricting the filter to --- the old wrapper prefix keeps the inverse exact — rows this migration never --- touched (a new daemon writes skill_bundle_unavailable directly, with a --- "skill bundle unavailable: ..." error string) are left alone rather than --- being relabelled into a bucket they were never in. -UPDATE agent_task_queue -SET failure_reason = 'agent_error.unknown' -WHERE status = 'failed' - AND failure_reason = 'skill_bundle_unavailable' - AND error LIKE 'resolve skill bundles:%'; - -UPDATE chat_message -SET failure_reason = 'agent_error.unknown' -WHERE failure_reason = 'skill_bundle_unavailable' - AND content LIKE 'resolve skill bundles:%'; diff --git a/server/migrations/233_backfill_skill_bundle_unavailable.up.sql b/server/migrations/233_backfill_skill_bundle_unavailable.up.sql deleted file mode 100644 index af8ad491f1..0000000000 --- a/server/migrations/233_backfill_skill_bundle_unavailable.up.sql +++ /dev/null @@ -1,33 +0,0 @@ --- Backfill the skill_bundle_unavailable reason introduced in MUL-5370. --- --- The daemon now labels "could not download the agent's skill bundles" --- structurally instead of letting the wrapped transport error fall through --- taskfailure.Classify into agent_error.unknown. That change is forward-only: --- historical rows still sit in the unknown bucket, which makes the failure --- invisible on the Usage page's Errors breakdown — exactly the observability --- gap that let this bug survive in the wild. --- --- The witness is the old wrapper prefix these rows were written with --- ("resolve skill bundles: ..."), which is stable and unambiguous: no other --- code path produced it. --- --- Scoped to agent_error.unknown alone, and that is exhaustive rather than --- conservative: the wrapper string first shipped 2026-06-23 (MUL-3281, --- 5038c983c), three weeks after the in-flight classifier landed 2026-06-03 --- (MUL-2946, 10afd1af1). Every row that can carry this prefix was therefore --- written through taskfailure.Classify and landed in agent_error.unknown -- --- none can hold the pre-MUL-1949 coarse 'agent_error'. Keeping the source --- bucket single-valued is what makes the down migration an exact inverse. -UPDATE agent_task_queue -SET failure_reason = 'skill_bundle_unavailable' -WHERE status = 'failed' - AND failure_reason = 'agent_error.unknown' - AND error LIKE 'resolve skill bundles:%'; - --- chat_message mirrors the task's failure_reason for chat turns, and the chat --- bubble reads it directly — leaving these behind would keep showing the --- generic "something went wrong" copy on historical turns. -UPDATE chat_message -SET failure_reason = 'skill_bundle_unavailable' -WHERE failure_reason = 'agent_error.unknown' - AND content LIKE 'resolve skill bundles:%';