mirror of
https://github.com/nestriness/nestri.git
synced 2026-09-20 01:35:19 +03:00
9258c8dfef
Six defects found by running the thing rather than reading it. The previous change was verified by bundling, by tests, and by the container images — none of which start a Worker, so every one of these was invisible. **`bun dev` did not start.** It ran one multi-config process, which does not connect a service binding between the workers it loads; the API reported `AUTH [not connected]` and could not verify a token. It is two processes now, which is what the dev registry connects, and the second is backgrounded with the first killed on exit so stopping the pair stops both. **Neither server could bind.** Wrangler resolves `localhost` and takes `::1` first; a host with no IPv6 address on its loopback dies with a bind error from inside the runtime that names neither the app nor the port. `dev.ip` is pinned to `127.0.0.1`, and `inspector_port` is now distinct per app — it is not derived from the port above, so the second server to start died on an address already in use. **The API worker failed to evaluate.** A specifier ending in `.sql` is claimed by the bundler as a module of its own, so the schema file was emitted verbatim beside the bundle and the runtime threw on an export it could not find. The route was reaching past the domain module into the schema to spell a status; it now asks the domain module, which is the rule everywhere else here and happens to also avoid the hazard. **Signing in failed on the second request that touched the database.** A pool is cached per connection string, and on a Worker an I/O object created while handling one request may not be touched while handling another. The first request always succeeded, which is why it went unnoticed — a sign-in is several. The cache is now kept only where a process outlives its requests, which is the case it was added for. **The images named a base that podman will not resolve.** A short name needs a registry; the database service alongside them already spelled one. **Compose pinned container names.** The name is not scoped to the project, so a second checkout got the same three, and `down` in one stopped the other's containers. This is not hypothetical — it stopped a running development database while this was being tested. Verified by signing in end to end against both dev servers: a code requested over HTTP, read from the issuer's log, redeemed, exchanged for tokens, and presented to the API, which resolved it to the account the sign-in had just created.
70 lines
2.9 KiB
JSON
70 lines
2.9 KiB
JSON
// The issuer, deployed as a Cloudflare Worker.
|
|
//
|
|
// The same `src/index.ts` also runs as an ordinary HTTP server — see
|
|
// `src/server.ts` and the `Dockerfile` beside it. Nothing in the handler is
|
|
// Workers-specific; what differs between the two is only where the settings
|
|
// below come from, so this file and the container's environment are two
|
|
// spellings of one list.
|
|
//
|
|
// Hostnames and the reasoning behind their shape: `docs/dns.md`.
|
|
// Secrets, the Hyperdrive id, and how to deploy: `docs/deploy.md`.
|
|
{
|
|
"$schema": "node_modules/wrangler/config-schema.json",
|
|
"name": "nestri-auth",
|
|
"main": "src/index.ts",
|
|
"compatibility_date": "2026-09-05",
|
|
"compatibility_flags": ["nodejs_compat"],
|
|
// No `*.workers.dev` hostname. A second address that mints tokens is a
|
|
// second issuer as far as a token's `iss` claim is concerned, and every
|
|
// token minted through it is rejected by the API.
|
|
"workers_dev": false,
|
|
// `ip` is pinned rather than left to default. Wrangler otherwise binds
|
|
// whatever `localhost` resolves to, which is `::1` first on most systems
|
|
// — and a host with no IPv6 address on its loopback interface fails to
|
|
// start at all, with a bind error from deep inside the runtime rather
|
|
// than anything naming a port.
|
|
"dev": {
|
|
"ip": "127.0.0.1",
|
|
"port": 1337,
|
|
// Distinct per app. Both dev servers run at once and the debugger
|
|
// port is not derived from the one above, so leaving it default
|
|
// meant the second to start died on an address already in use.
|
|
"inspector_port": 9229
|
|
},
|
|
|
|
// Local-only settings live in `.dev.vars` beside this file rather than in
|
|
// `vars` here. `wrangler dev` reads that file and `wrangler deploy` cannot
|
|
// upload it — which is the guarantee wanted for the one setting in it:
|
|
// printing a live sign-in code to the log is a thing you ask for by name,
|
|
// and no stage anybody else can reach may have it. Written as a `vars`
|
|
// entry it would be one forgotten override away from being deployed.
|
|
|
|
// The default environment is the local one. `localConnectionString` is what
|
|
// `wrangler dev` uses, so a checkout with `docker compose up postgres`
|
|
// running needs nothing else; `id` is only read on deploy, and the two
|
|
// named environments below carry their own.
|
|
"hyperdrive": [
|
|
{
|
|
"binding": "HYPERDRIVE",
|
|
"id": "0000000000000000000000000000dev0",
|
|
"localConnectionString": "postgres://postgres:postgres@localhost:5432/nestri"
|
|
}
|
|
],
|
|
"env": {
|
|
"sandbox": {
|
|
"name": "nestri-auth-sandbox",
|
|
"workers_dev": false,
|
|
"routes": [{ "pattern": "auth.sandbox.nestri.io", "custom_domain": true }],
|
|
"observability": { "enabled": true },
|
|
"hyperdrive": [{ "binding": "HYPERDRIVE", "id": "<sandbox-hyperdrive-id>" }]
|
|
},
|
|
"production": {
|
|
"name": "nestri-auth",
|
|
"workers_dev": false,
|
|
"routes": [{ "pattern": "auth.nestri.io", "custom_domain": true }],
|
|
"observability": { "enabled": true },
|
|
"hyperdrive": [{ "binding": "HYPERDRIVE", "id": "<production-hyperdrive-id>" }]
|
|
}
|
|
}
|
|
}
|