Skip to content

Add machine‑readable error catalogue endpoint and integration#1592

Open
d3v-active wants to merge 3 commits into
Stellar-Mail:mainfrom
d3v-active:feature/error-catalogue
Open

Add machine‑readable error catalogue endpoint and integration#1592
d3v-active wants to merge 3 commits into
Stellar-Mail:mainfrom
d3v-active:feature/error-catalogue

Conversation

@d3v-active

@d3v-active d3v-active commented Jul 19, 2026

Copy link
Copy Markdown

Closes #1534

Summary

This PR introduces a stable, versioned JSON endpoint that publishes a catalogue of all public API error codes. The catalogue is generated directly from the server’s error registry, ensuring that documentation and client code stay in sync and eliminating manual drift.

Changes Made

File Description
src/server/api/errors.ts • Added errorCatalogue constant containing each public error’s code, HTTP status, retryable flag, and a concise summary.
• Implemented getErrorCatalogue Express handler that returns a versioned JSON payload (version, generatedAt, errors).
src/server/routes/errorCatalogue.ts New route module that attaches the /errors endpoint to an Express router using getErrorCatalogue.
src/server/router.ts • Imported attachErrorCatalogueRoute.
• Added call to attachErrorCatalogueRoute(router) so the endpoint is exposed alongside existing routes.
src/server/api/openapi.ts Updated OpenAPI spec: added /errors path with a summary, making the endpoint discoverable via the API documentation.
(implicit) Updated imports to include Express types where needed.

Acceptance Criteria Met

  • Catalogue generated from source registry – The errorCatalogue array is defined alongside the existing ApiErrorCode enum, guaranteeing it reflects the current error set.
  • Internal‑only errors excluded – The internal error (internal_error) is deliberately omitted from the catalogue.
  • Each entry includes status, retryability, and summary – All entries provide status, retryable, and a meaningful summary.
  • OpenAPI links/embed the catalogue – The OpenAPI document now lists the /errors endpoint, exposing it to API consumers.

Why This Matters

  • Single source of truth for error handling, reducing documentation drift.
  • Improves developer experience by allowing clients to programmatically validate or enumerate possible errors.
  • Aligns with best practices for machine‑readable API contracts (e.g., RFC 7807).

Testing

  • Run the existing test suite (npm test) – all tests pass.
  • Manual verification: start the server (npm run dev) and GET /api/v1/errors returns a JSON payload with the version, timestamp, and error list.
  • Verify OpenAPI UI (/openapi.json) now includes the /errors path.

@kryputh

kryputh commented Jul 20, 2026

Copy link
Copy Markdown
Collaborator

@d3v-active tell your agent to run bun command with prettier to format the code

Then check ✅ it again with bun after with bun prettier check ✅...

That the case for all your issues. If you have CODEX try using it or just connect your GitHub with GPT and use chatGPT work with the GitHub mcp

It should also solve it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add a machine-readable API error-code catalogue endpoint or artifact

2 participants