# @constructive-io/errors

Canonical Constructive error system. Zero runtime dependencies — usable by any
service or client without pulling in pgpm.

- **Registry** — the single source of truth mapping each stable `code` to its
  classification (`public` vs `internal`), HTTP hint, and default message.
- **`parse(anyError)`** — normalize an error from any source (a
  `ConstructiveError`, a node-postgres `DatabaseError`, a GraphQL error or
  `{ errors: [...] }` wrapper, a plain `Error`, or a string) into a canonical
  `{ code, context, class, known }`.
- **`format(code, context, locale)`** — render a localized, interpolated
  message. `{{var}}` placeholders + registerable per-locale catalogs (i18n).
- **`errors.*` factory** — type-safe throwable builders derived from the
  registry, e.g. `throw errors.MODULE_NOT_FOUND({ name })`.
- **`classify(code)`** — `public` or `internal`; unknown codes are `internal`
  (fail safe) so transports never leak unregistered errors.
- **`httpStatusFor(code)`** — the canonical code → HTTP status mapping, so no
  transport keeps its own table. Unregistered codes answer `500` *and are
  reported*, never silently.

```ts
import { parse, format, errors, classify } from '@constructive-io/errors';

// Normalize a DB error surfaced through GraphQL
const parsed = parse(graphqlError);
if (parsed.class === 'public') {
  showUser(format(parsed.code!, parsed.context, locale));
}

// Throw a structured error
throw errors.ACCOUNT_EXISTS();
```

## Design notes

- The machine `code` is deliberately separate from user-facing copy so codes
  are stable and messages are localizable.
- `parse()` recovers structure from the code's precedence: structured `DETAIL`
  JSON → GraphQL `extensions.code` → a leading ALL_CAPS token in the message
  (legacy DB `RAISE`, incl. `CODE (arg, arg)` positional args) → native
  SQLSTATE constraint mapping.
- The registry has two layers, merged at lookup time (curated wins):
  - **Generated** (`src/generated/registry.generated.ts`) — every code raised via
    `EXCEPTION`/`THROW` across constructive-db (deploy sources + generated output),
    each with a `public`/`internal` class, HTTP hint, and default message.
  - **Curated** (`src/registry.ts`) — refined, typed-context entries for the codes
    that matter most (public auth/limit copy, native PostgreSQL constraint codes,
    pgpm CLI codes). These override the generated entries.
- Unregistered codes still `parse()` and are classified `internal` (masked).

## HTTP status

Every registry entry carries `http`, so an HTTP surface never needs its own
code → status table: `toError(err).http`, or `httpStatusFor(code)` when all you
have is a code.

```ts
import { httpStatusFor, setUnmappedStatusReporter, toError } from '@constructive-io/errors';

setUnmappedStatusReporter(code => log.warn({ code }, 'error code has no HTTP status'));

const err = toError(caught);
res.status(err.http).json(err.toExtensions());

httpStatusFor('ACCOUNT_DISABLED'); // { status: 403, mapped: true }
httpStatusFor('BRAND_NEW_CODE');   // { status: 500, mapped: false } + one report
```

`mapped: false` is the one case where a 500 does not mean "the server broke" —
it means the code never reached the registry. That is the failure mode this
exists to make loud: a refusal that is plainly a 403 or a 409 answering 500
looks like a crash, and the codes most likely to be missing are the newest ones.
When a constructive-db release adds codes, refresh the registry (below);
`__tests__/registry-sync.test.ts` fails if the snapshot and the generated
registry disagree.

## Regenerating the full registry

The generated layer is produced from a committed audit snapshot:

```bash
# 1. re-audit constructive-db (refreshes scripts/db-error-inventory.json)
CONSTRUCTIVE_DB_DIR=~/repos/constructive-db python3 scripts/audit-db-errors.py
# 2. regenerate src/generated/registry.generated.ts from the snapshot
python3 scripts/generate-registry.py
```

`audit-db-errors.py` scans every `EXCEPTION`/`THROW` across constructive-db deploy
sources and generated output and writes `scripts/db-error-inventory.json` (the
committed audit snapshot). It also captures the authoritative `public`/`internal`
class from each canonical `errors.raise_error('CODE', context, 'class')` call — the
database is the source of truth for classification, so an explicit class is trusted
directly; codes without one (e.g. single-arg calls relying on the helper default, or
legacy `RAISE EXCEPTION`) fall back to a name-based heuristic.
`generate-registry.py` reads that snapshot and, when a
`constructive-io/dashboard` checkout is found (via `DASHBOARD_DIR` or a sibling
`../dashboard`), seeds public copy from its error catalogs. Re-run both whenever
constructive-db error codes change. Never hand-edit the generated file.

---

## Education and Tutorials

 1. 🚀 [Quickstart: Getting Up and Running](https://constructive.io/learn/quickstart)
Get started with modular databases in minutes. Install prerequisites and deploy your first module.

 2. 📦 [Modular PostgreSQL Development with Database Packages](https://constructive.io/learn/modular-postgres)
Learn to organize PostgreSQL projects with pgpm workspaces and reusable database modules.

 3. ✏️ [Authoring Database Changes](https://constructive.io/learn/authoring-database-changes)
Master the workflow for adding, organizing, and managing database changes with pgpm.

 4. 🧪 [End-to-End PostgreSQL Testing with TypeScript](https://constructive.io/learn/e2e-postgres-testing)
Master end-to-end PostgreSQL testing with ephemeral databases, RLS testing, and CI/CD automation.

 5. ⚡ [Supabase Testing](https://constructive.io/learn/supabase)
Use TypeScript-first tools to test Supabase projects with realistic RLS, policies, and auth contexts.

 6. 💧 [Drizzle ORM Testing](https://constructive.io/learn/drizzle-testing)
Run full-stack tests with Drizzle ORM, including database setup, teardown, and RLS enforcement.

 7. 🔧 [Troubleshooting](https://constructive.io/learn/troubleshooting)
Common issues and solutions for pgpm, PostgreSQL, and testing.

## Related Constructive Tooling

### 📦 Package Management

* [pgpm](https://github.com/constructive-io/constructive/tree/main/pgpm/pgpm): **🖥️ PostgreSQL Package Manager** for modular Postgres development. Works with database workspaces, scaffolding, migrations, seeding, and installing database packages.

### 🧪 Testing

* [pgsql-test](https://github.com/constructive-io/constructive/tree/main/postgres/pgsql-test): **📊 Isolated testing environments** with per-test transaction rollbacks—ideal for integration tests, complex migrations, and RLS simulation.
* [pglite-test](https://github.com/constructive-io/constructive/tree/main/postgres/pglite-test): **🪶 Drop-in pgsql-test replacement backed by PGlite** — in-process Postgres, no server required, instance-per-suite isolation.
* [pgsql-seed](https://github.com/constructive-io/constructive/tree/main/postgres/pgsql-seed): **🌱 PostgreSQL seeding utilities** for CSV, JSON, SQL data loading, and pgpm deployment.
* [supabase-test](https://github.com/constructive-io/constructive/tree/main/postgres/supabase-test): **🧪 Supabase-native test harness** preconfigured for the local Supabase stack—per-test rollbacks, JWT/role context helpers, and CI/GitHub Actions ready.
* [graphile-test](https://github.com/constructive-io/constructive/tree/main/graphile/graphile-test): **🔐 Authentication mocking** for Graphile-focused test helpers and emulating row-level security contexts.
* [pg-query-context](https://github.com/constructive-io/constructive/tree/main/postgres/pg-query-context): **🔒 Session context injection** to add session-local context (e.g., `SET LOCAL`) into queries—ideal for setting `role`, `jwt.claims`, and other session settings.

### 🧠 Parsing & AST

* [pgsql-parser](https://www.npmjs.com/package/pgsql-parser): **🔄 SQL conversion engine** that interprets and converts PostgreSQL syntax.
* [libpg-query-node](https://www.npmjs.com/package/libpg-query): **🌉 Node.js bindings** for `libpg_query`, converting SQL into parse trees.
* [pg-proto-parser](https://www.npmjs.com/package/pg-proto-parser): **📦 Protobuf parser** for parsing PostgreSQL Protocol Buffers definitions to generate TypeScript interfaces, utility functions, and JSON mappings for enums.
* [@pgsql/enums](https://www.npmjs.com/package/@pgsql/enums): **🏷️ TypeScript enums** for PostgreSQL AST for safe and ergonomic parsing logic.
* [@pgsql/types](https://www.npmjs.com/package/@pgsql/types): **📝 Type definitions** for PostgreSQL AST nodes in TypeScript.
* [@pgsql/utils](https://www.npmjs.com/package/@pgsql/utils): **🛠️ AST utilities** for constructing and transforming PostgreSQL syntax trees.

### 📚 Documentation & Skills

* [constructive-skills](https://github.com/constructive-io/constructive-skills): **📖 Platform documentation and AI agent skills** — feature catalog, blueprint reference, SDK guides (i18n, billing, limits, events, uploads, security, entities, search, AI), and deployment guides.

Install skills for AI coding agents:

```bash
# All platform skills (security, blueprints, codegen, billing, etc.)
npx skills add constructive-io/constructive-skills

# Individual repo skills (pgpm, testing, CLI, search, etc.)
npx skills add https://github.com/constructive-io/constructive --skill pgpm
npx skills add https://github.com/constructive-io/constructive --skill constructive-testing
```

## Credits

**🛠 Built by the [Constructive](https://constructive.io) team — creators of modular Postgres tooling for secure, composable backends. If you like our work, contribute on [GitHub](https://github.com/constructive-io).**

## Disclaimer

AS DESCRIBED IN THE LICENSES, THE SOFTWARE IS PROVIDED "AS IS", AT YOUR OWN RISK, AND WITHOUT WARRANTIES OF ANY KIND.

No developer or entity involved in creating this software will be liable for any claims or damages whatsoever associated with your use, inability to use, or your interaction with other users of the code, including any direct, indirect, incidental, special, exemplary, punitive or consequential damages, or loss of profits, cryptocurrencies, tokens, or anything else of value.