[Bug] Security scan task can run before publish transaction commits

[XiaoSeS]

Summary

SecurityScanService.triggerScan is transactional, but it publishes the Redis Stream scan task inline before the database transaction commits.

The consumer can receive the task before the new skill_version / security_audit rows are visible. It then fails with SkillVersion not found or SecurityAudit not found. The current stream consumer retries immediately and acknowledges each failed message; all retries can be exhausted while the publishing transaction is still open, leaving the committed version stuck in SCANNING.

Current code:

• triggerScan publishes inside the transaction
• Retries are re-published immediately and the failed message is acknowledged

Steps To Reproduce

1. Enable the security scanner and Redis Stream consumer.
2. Add a transaction delay after triggerScan publishes the task but before the publish transaction commits, or run with a fast consumer and a slow database transaction.
3. Publish a public or namespace-only skill version.
4. Observe the consumer receive the task before the version/audit rows are committed.
5. The consumer retries the same task immediately; under a sufficiently long transaction, all retries fail.
6. The publish request commits, but the version remains SCANNING with no successful scan result.

A deterministic regression test can use a transaction barrier/latch and assert that ScanTaskProducer.publishScanTask is not called until after commit.

Expected Behavior

The scan task should become visible only after the transaction that creates/updates the version and audit rows commits.

Typical options:

• register an afterCommit synchronization before publishing; or
• use an outbox/event mechanism with commit-coupled delivery.

When no transaction is active, immediate publishing can remain supported.

Environment

• Branch: main
• Commit: 9f602f8184f23347124b3606ffce1a6ac5f19c0a
• Scanner mode: both local and upload modes are affected by task timing

API Contract Impact

No API shape change. This fixes an asynchronous lifecycle race after publish.

Logs Or Screenshots

Representative errors:

SkillVersion not found: <versionId>
SecurityAudit not found for versionId=<versionId>

[github-actions]

Issue Triage

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

Why

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

High-Risk Signals

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

Maintainer Brief

Summary: security_audit rows are visible. It then fails with SkillVersion not found or SecurityAudit not found. The current stream consumer retries immediately and acknowledges each failed message; all retries can be exhausted while the publishing transaction is still open, leaving the committed version stuck in SCANNING. Current code: - triggerScan publishes inside the transaction - Retries are re-published immediately and the failed message is acknowledged
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 (security).
• Issue mentions API, SDK, or contract changes.
  Reproduction or operator path:
• 1. Enable the security scanner and Redis Stream consumer.
• 2. Add a transaction delay after triggerScan publishes the task but before the publish transaction commits, or run with a fast consumer and a slow database transaction.
• 3. Publish a public or namespace-only skill version.
• 4. Observe the consumer receive the task before the version/audit rows are committed.
• 5. The consumer retries the same task immediately; under a sufficiently long transaction, all retries fail.
     Suspected areas:
• CLI publish command option parsing and namespace-aware publish flow
• Local skill sync flow and publish diff detection
• Security scanner pipeline and audit/reporting behavior
  Risks to watch:
• Mentions sensitive areas (security).
• 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: The scan task should become visible only after the transaction that creates/updates the version and audit rows commits. Typical options: - register an afterCommit synchronization before publishing; or - use an outbox/event mechanism with commit-coupled delivery. When no transaction is active, immediate publishing can remain supported.
• 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.1/5)
• 修复投入: effort/l (4/5)
• 信息完整度: 5/5
• 风险: 高
• 分析模式: rules-only

原因

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

高风险信号

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

维护者交接摘要

概要: SecurityScanService.triggerScan is transactional, but it publishes the Redis Stream scan task inline before the database transaction commits. The consumer can receive the task before the new skill_version
为何进入 core:

• 触及高风险区域，未经 maintainer 审查不应直接信任自动修复
• 大概率跨多个模块或公共兼容面
• 提到敏感区域（security）
• 提到 API、SDK 或契约变更
  复现路径或操作路径:
• 1. Enable the security scanner and Redis Stream consumer.
• 2. Add a transaction delay after triggerScan publishes the task but before the publish transaction commits, or run with a fast consumer and a slow database transaction.
• 3. Publish a public or namespace-only skill version.
• 4. Observe the consumer receive the task before the version/audit rows are committed.
• 5. The consumer retries the same task immediately; under a sufficiently long transaction, all retries fail.
     怀疑影响区域:
• CLI 发布命令参数解析与 namespace 感知发布流程
• 本地技能同步流程与发布 diff 检测
• 安全扫描流程与审计/报告行为
  重点风险:
• 提到敏感区域（security）
• 提到 API、SDK 或契约变更
• namespace 范围行为如果没有保留 fallback routing，可能回归默认 publish/install 流程
  验证清单:
• 按 issue 中的复现步骤逐条回放，确认报告的问题已消失
• 确认最终行为符合 issue 期望
• 同时验证 namespace 范围行为与默认非 namespace 流程

下一步

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