Skip to content

Create endpoints return 201 while OpenAPI documents only 200 #577

Description

@MicroMilo

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions