Summary
Several create operations return 201 Created at runtime, but api-contract.yaml documents only 200 responses for those operations. Strict OpenAPI validators, API gateways, or generated SDKs can treat these successful responses as outside the contract.
Affected operations:
createAgent
createOrUpdateNote
createWorkspace
Minimal Reproduction
Compare OpenAPI response buckets with handler return status:
createAgent: OpenAPI declares only "200"; src/app/api/agents/route.ts returns { status: 201 }.
createOrUpdateNote: OpenAPI declares only "200"; src/app/api/notes/route.ts returns { status: 201 }.
createWorkspace: OpenAPI declares only "200"; src/app/api/workspaces/route.ts returns { status: 201 }.
Evidence
api-contract.yaml:1355-1379 documents createAgent with only response "200".
api-contract.yaml:2044-2070 documents createOrUpdateNote with only response "200".
api-contract.yaml:2191-2214 documents createWorkspace with only response "200".
src/app/api/agents/route.ts:68 returns NextResponse.json(result.data, { status: 201 }).
src/app/api/notes/route.ts:167 returns NextResponse.json({ note: serializeNote(note) }, { status: 201 }).
src/app/api/workspaces/route.ts:48 returns NextResponse.json({ workspace: serializeWorkspace(workspace) }, { status: 201 }).
tests/api-contract/test-agents.ts:35-36, tests/api-contract/test-notes.ts:34, and tests/api-contract/test-workspaces.ts:39 accept either 200 or 201.
tests/api-contract/test-schema-validation.ts:138-140, tests/api-contract/test-schema-validation.ts:189-202, and tests/api-contract/test-schema-validation.ts:380-393 accept 200/201 but then validate against the 200 response bucket.
Actual Behavior
The runtime returns successful 201 responses that are not declared in OpenAPI for these operations.
Expected Behavior
OpenAPI, handlers, and contract tests should agree on the status code. Since the handlers and createTask use 201, the natural fix is to document 201 for create responses, or explicitly change the handlers to return 200 if that is the intended contract.
Existing Issue / PR Coverage
Checked open and closed issues/PRs with:
createWorkspace createAgent 201 api-contract 200
test-schema-validation createWorkspace 200 201
No direct PR coverage was found.
Related but not covering this bug:
Those issues are unrelated to OpenAPI response status drift.
Proposed Fix
- Add/replace
201 response buckets for createAgent, create-note behavior, and createWorkspace, or change the handlers to match 200.
- Update schema-validation tests to validate against the actual returned status.
- Remove broad
200 || 201 assertions unless both statuses are declared in OpenAPI.
Suggested Tests
createAgent returning 201 validates against a 201 response bucket.
createWorkspace returning 201 validates against a 201 response bucket.
createOrUpdateNote distinguishes create vs update status, or documents one unified status contract.
Summary
Several create operations return
201 Createdat runtime, butapi-contract.yamldocuments only200responses for those operations. Strict OpenAPI validators, API gateways, or generated SDKs can treat these successful responses as outside the contract.Affected operations:
createAgentcreateOrUpdateNotecreateWorkspaceMinimal Reproduction
Compare OpenAPI response buckets with handler return status:
createAgent: OpenAPI declares only"200";src/app/api/agents/route.tsreturns{ status: 201 }.createOrUpdateNote: OpenAPI declares only"200";src/app/api/notes/route.tsreturns{ status: 201 }.createWorkspace: OpenAPI declares only"200";src/app/api/workspaces/route.tsreturns{ status: 201 }.Evidence
api-contract.yaml:1355-1379documentscreateAgentwith only response"200".api-contract.yaml:2044-2070documentscreateOrUpdateNotewith only response"200".api-contract.yaml:2191-2214documentscreateWorkspacewith only response"200".src/app/api/agents/route.ts:68returnsNextResponse.json(result.data, { status: 201 }).src/app/api/notes/route.ts:167returnsNextResponse.json({ note: serializeNote(note) }, { status: 201 }).src/app/api/workspaces/route.ts:48returnsNextResponse.json({ workspace: serializeWorkspace(workspace) }, { status: 201 }).tests/api-contract/test-agents.ts:35-36,tests/api-contract/test-notes.ts:34, andtests/api-contract/test-workspaces.ts:39accept either 200 or 201.tests/api-contract/test-schema-validation.ts:138-140,tests/api-contract/test-schema-validation.ts:189-202, andtests/api-contract/test-schema-validation.ts:380-393accept 200/201 but then validate against the 200 response bucket.Actual Behavior
The runtime returns successful 201 responses that are not declared in OpenAPI for these operations.
Expected Behavior
OpenAPI, handlers, and contract tests should agree on the status code. Since the handlers and
createTaskuse201, the natural fix is to document201for create responses, or explicitly change the handlers to return200if that is the intended contract.Existing Issue / PR Coverage
Checked open and closed issues/PRs with:
createWorkspace createAgent 201 api-contract 200test-schema-validation createWorkspace 200 201No direct PR coverage was found.
Related but not covering this bug:
Those issues are unrelated to OpenAPI response status drift.
Proposed Fix
201response buckets forcreateAgent, create-note behavior, andcreateWorkspace, or change the handlers to match200.200 || 201assertions unless both statuses are declared in OpenAPI.Suggested Tests
createAgentreturning 201 validates against a 201 response bucket.createWorkspacereturning 201 validates against a 201 response bucket.createOrUpdateNotedistinguishes create vs update status, or documents one unified status contract.