[Bug] Concurrent publishes race on skill coordinate and return 500

[XiaoSeS]

Summary

Skill lifecycle mutations are not serialized by the final (namespace_id, slug) coordinate.

In the publish flow, the service performs a check-then-create sequence:

1. query skills by namespace/slug;
2. query the current owner's skill;
3. insert the skill if absent;
4. query/replace/create a version.

Two concurrent publishes for the same owner, namespace, slug, and version can both observe “not found” and race on the database uniqueness constraints. One request then returns an unhandled DataIntegrityViolationException as HTTP 500. Concurrent publish/review mutations can also interleave pending-review withdrawal and latest_version_id updates.

Current code:

• Publish check-then-create and version lookup
• skill(namespace_id, slug, owner_id) unique constraint
• skill_version(skill_id, version) unique constraint

Steps To Reproduce

1. Prepare a valid publish package for a new skill/version.
2. Use the same user and namespace in two concurrent publish requests.
3. Add a barrier after both transactions finish the “find existing skill/version” reads and before either insert, to make the race deterministic.
4. Release both requests.
5. Observe one request succeed and the other fail with a unique-constraint exception / HTTP 500.

A second regression test should run publish and review approval concurrently on the same skill coordinate and assert deterministic lifecycle state.

Expected Behavior

Mutations for the same final skill coordinate should be serialized or otherwise use an atomic upsert/conflict protocol.

Concurrent identical requests should result in either:

• one success and one deterministic business conflict/idempotent response; or
• two serialized, valid outcomes.

They should not produce an internal server error or leave ambiguous lifecycle pointers.

Environment

• Branch: main
• Commit: 9f602f8184f23347124b3606ffce1a6ac5f19c0a
• Database: PostgreSQL

API Contract Impact

No response-shape change is required. Contention should stop surfacing as HTTP 500.

Logs Or Screenshots

Representative database symptoms:

duplicate key value violates unique constraint "skill_namespace_id_slug_owner_id_key"
duplicate key value violates unique constraint on skill_version(skill_id, version)

[github-actions]

Issue Triage

• Route: triage/core
• Priority: priority/p1 (4.2/5)
• Effort: effort/l (4/5)
• Confidence: 5/5
• Risk: high
• Analysis Mode: rules-only

Why

• Touches core SkillHub workflows (publish, review, namespace).
• Contains urgency signals (regression, 500).
• Text suggests a bounded change (text).

High-Risk Signals

• Mentions sensitive areas (migration).
• Issue mentions API, SDK, or contract changes.

Maintainer Brief

Summary: Skill lifecycle mutations are not serialized by the final (namespace_id, slug) coordinate. In the publish flow, the service performs a check-then-create sequence: 1. query skills by namespace/slug; 2. query the current owner's skill; 3. insert the skill if absent; 4. query/replace/create a version. Two concurrent publishes for the same owner, namespace, slug, and version can both observe “not found” and race on the database uniqueness constraints. One request then returns an unhandled DataIntegrityViolationException as HTTP 500. Concurrent publish/review mutations can also interleave pending-review withdrawal and latest_version_id updates. Current code: - Publish check-then-create and version lookup - skill(namespace_id, slug, owner_id) unique constraint - skill_version(skill_id, version) unique constraint
Why core:

• Touches a higher-risk area where automated fixes should not be trusted without maintainer review.
• Likely spans multiple modules or a public compatibility surface.
• Mentions sensitive areas (migration).
• Issue mentions API, SDK, or contract changes.
  Reproduction or operator path:
• 1. Prepare a valid publish package for a new skill/version.
• 2. Use the same user and namespace in two concurrent publish requests.
• 3. Add a barrier after both transactions finish the “find existing skill/version” reads and before either insert, to make the race deterministic.
• 4. Release both requests.
• HTTP 500.
  Suspected areas:
• CLI publish command option parsing and namespace-aware publish flow
• Installed skill update flow and version resolution
  Risks to watch:
• Mentions sensitive areas (migration).
• Issue mentions API, SDK, or contract changes.
• Namespace-scoped behavior can regress default publish/install flows if fallback routing is not preserved.
  Validation checklist:
• Replay the exact reproduction steps from the issue and confirm the reported failure disappears.
• Confirm the final behavior matches the issue's expected outcome: Mutations for the same final skill coordinate should be serialized or otherwise use an atomic upsert/conflict protocol. Concurrent identical requests should result in either: - one success and one deterministic business conflict/idempotent response; or - two serialized, valid outcomes. They should not produce an internal server error or leave ambiguous lifecycle pointers.
• Verify both namespace-scoped behavior and the default non-namespace flow.

Next Action

• Hand the issue to a core maintainer and use a local programming agent for reproduction, scoping, and validation.

---

问题分流结果

• 路由: triage/core
• 优先级: priority/p1 (4.2/5)
• 修复投入: effort/l (4/5)
• 信息完整度: 5/5
• 风险: 高
• 分析模式: rules-only

原因

• 涉及 SkillHub 核心流程（publish, review, namespace）
• 包含紧急信号（regression, 500）
• 文本显示改动范围较可控（text）

高风险信号

• 提到敏感区域（migration）
• 提到 API、SDK 或契约变更

维护者交接摘要

概要: Skill lifecycle mutations are not serialized by the final (namespace_id, slug) coordinate. In the publish flow, the service performs a check-then-create sequence: 1. query skills by namespace/slug; 2. query the current owner's skill; 3. insert the skill if absent; 4. query/replace/create a version. Two concurrent publishes for the same owner, namespace, slug, and version can both observe “not found” and race on the database uniqueness constraints. One request then returns an unhandled DataIntegrityViolationException as HTTP 500. Concurrent publish/review mutations can also interleave pending-review withdrawal and latest_version_id updates. Current code: - Publish check-then-create and version lookup - skill(namespace_id, slug, owner_id) unique constraint - skill_version(skill_id, version) unique constraint
为何进入 core:

• 触及高风险区域，未经 maintainer 审查不应直接信任自动修复
• 大概率跨多个模块或公共兼容面
• 提到敏感区域（migration）
• 提到 API、SDK 或契约变更
  复现路径或操作路径:
• 1. Prepare a valid publish package for a new skill/version.
• 2. Use the same user and namespace in two concurrent publish requests.
• 3. Add a barrier after both transactions finish the “find existing skill/version” reads and before either insert, to make the race deterministic.
• 4. Release both requests.
• 5. Observe one request succeed and the other fail with a unique-constraint exception
     怀疑影响区域:
• CLI 发布命令参数解析与 namespace 感知发布流程
• 已安装技能更新流程与版本解析
  重点风险:
• 提到敏感区域（migration）
• 提到 API、SDK 或契约变更
• namespace 范围行为如果没有保留 fallback routing，可能回归默认 publish/install 流程
  验证清单:
• 按 issue 中的复现步骤逐条回放，确认报告的问题已消失
• 确认最终行为符合 issue 期望
• 同时验证 namespace 范围行为与默认非 namespace 流程

下一步

• 交给 core maintainer，并结合本地编程Agent协助完成复现、收敛范围与验证闭环

[XiaoSeS]

/retriage