Make create-operation semantics consistent across all project-scoped catalog entities (create-or-fail vs upsert)
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 42/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- typescript
調査の方向性
Start by re-confirming the listed create behaviors for each catalog entity across the API, portal, and CLI. Decide whether each entity should use create-or-fail or an explicitly documented upsert path, then align the affected clients and add duplicate-create tests and documentation for every entity. Done means the convention, exceptions, API responses, portal behavior, and CLI handling are consistent and covered.
索引モデルが issue の本文から書いたものです。
説明
Original author: @cedricvidal
Summary
Create (POST) operations across our project-scoped catalog entities are inconsistent: some behave as create-or-update-if-exists (silent upsert / overwrite), others as create-or-fail-if-exists (409 on duplicate). We should pick one convention and apply it uniformly across the API, portal, and CLI.
This was surfaced while fixing the MCP "Add Server" duplicate-slug bug (PR #1241), where the create flow was silently overwriting an existing server. MCP was moved to create-or-fail (409) there; this issue tracks reconciling the rest.
Current behavior (audit)
| Entity | API create behavior | Portal client-side guard? |
|---|---|---|
| mcp-servers | CREATE-OR-FAIL (409) — fixed in #1241 | Yes (inline + toast) |
| criteria | CREATE-OR-FAIL | Yes |
| prompt-features | CREATE-OR-FAIL (409) | No — API rejects but portal doesn't pre-check |
| report-templates | CREATE-OR-FAIL (409) | Unverified |
| codebases | CREATE-OR-FAIL (unique-index E11000) | n/a |
| skills | UPSERT (findOne → updateOne/insertOne, 200/201) | n/a |
| extensions | UPSERT (same pattern as skills) | n/a |
| agents | UPSERT (explicit "upsert" semantics, 200/201) | — |
| agent-versions | UPSERT (by agentVersion) |
— |
| task-prompts | findOrCreate (always 201) | — |
File:line citations were gathered during the audit and can be reattached in the implementing PR. Treat the table as the starting inventory; each row should be re-confirmed before changing.
Problems
- Inconsistent, surprising semantics — the same "create" verb silently overwrites for some entities and rejects for others. A user re-adding an existing skill silently mutates it; re-adding an MCP server now errors.
- Data-loss risk — silent upsert on create can overwrite a record a user didn't intend to touch (the exact MCP bug).
- API/portal mismatch —
prompt-featuresreturns 409 from the API but the portal offers no client-side duplicate guard, so the user only discovers the conflict after submitting.
Proposed direction (to be decided)
Adopt create-or-fail (409) as the standard for user-facing catalog creates, with updates done explicitly via PUT. Rationale: least-surprise, no accidental overwrite, matches the MCP + criteria pattern.
- Some entities may have intentional idempotent re-import semantics (skills/extensions re-import, agent-version registration from workers). Those need an explicit decision: keep upsert (and document it) OR split into distinct create vs. update paths. Do not blanket-change without confirming each intent.
- Wherever the API is create-or-fail, add a matching portal client-side duplicate guard (inline error + disabled submit) for parity, and ensure the CLI surfaces the 409 cleanly.
Scope
- Out of scope for PR #1241 (per-project data organization). This is a follow-up.
- Deliverables: decision on the standard, per-entity reconciliation (API + portal + CLI), tests, and docs.
Acceptance criteria
- A documented, agreed convention for create-vs-update across catalog entities.
- Each entity's
POSTconforms (or its deviation is explicitly justified and documented). - Portal and CLI behavior matches the API for every entity (no silent-overwrite where the API 409s; no 409-only-after-submit where a pre-check is feasible).
- Tests cover the duplicate-create path per entity.
- 主要言語
- TypeScript
- スター
- 14
- フォーク
- 20
- 平均マージ
- 2日 12時間
- マージ済み PR（30日）
- 28
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
microsoft/scope のほかの issue
-
type: worker-update
難易度 1/5 1〜3時間 初心者へのやさしさ 85/100
メンテナーはふだん 1 日以内に返信
-
type: worker-update
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信
-
type: worker-update
難易度 1/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
Clarify that prompt features only categorize prompts, don't impact runs対応中かも @DerrickUnleashed が 12 日前に担当しました。 オープンauthor: JaGord documentation good first issue UI
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
Submit Run task prompt picker should only search requirement prompts対応中かも @cedricvidal が 78 日前に担当しました。 オープンauthor: cedricvidal bug portal
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
メンテナーはふだん 1 日以内に返信
microsoft/scope の issue をすべて見る
似ている issue
-
area:ui effort:S enhancement priority:P2
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
QuantumNous/new-api#7839 ·
メンテナーはふだん 1 日以内に返信
-
good first issue maintenance
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
dark-princezz/stellar-hooks#1010 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
interledger/rhyza#352 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
メンテナーはふだん 1 日以内に返信