o1-labs / o1-labs/Archive-Node-API
Epic: Production readiness — make Archive Node API publicly available
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 19
- Forks
- 9
- Avg merge
- 14h 20m
- Merged PRs (30d)
- 8
Description
Goal
Take the Archive Node API from "works in our hands" (v0.0.6) to production-ready software that can be exposed to an untrusted public audience.
The architecture is sound — modular service layer over postgres, read-replica fan-out, boot-time schema validation, multi-stage non-root Docker, multi-layer CI/CD, tracing, and good docs. The gaps are in hardening, operability, and observability rather than core design.
The single largest risk: today the service exposes a public GraphQL endpoint with no abuse protection (no query-cost limiting, no rate limiting, no DB query timeouts, CORS *). A single crafted query can exhaust the backing database. That class of issue is the P0 set below.
Tracked work
🔴 P0 — Blockers for a public endpoint
- #164 — GraphQL query-cost controls (depth / alias / complexity) — landed in #183
- #165 — Postgres pool limits +
statement_timeout— landed in #182 - #166 — Rate limiting (edge or in-process) — landed in #185
- #167 — Secure CORS default instead of
*— landed in #184 - #168 — Decide & document auth / TLS story — landed in #186
🟡 P1 — Strongly recommended before GA
- #169 — Readiness probe (DB ping) distinct from liveness — landed in #187
- #170 — Graceful shutdown: drain, flush traces, uncaught handlers — landed in #188
- #171 — Container hardening: node PID 1 / tini, HEALTHCHECK, pin digest — landed in #189
- #172 — Structured JSON logging with request IDs — #190 open
- #173 — Prometheus
/metrics(RED + DB pool saturation) — RED metrics landed in #191; DB pool-saturation gauges still open - #174 — Config validation at boot (fixes #74) — #193 open
- #175 — Supply chain: Dependabot, audit gate, image scan, SBOM — Dependabot, audit gate and SBOM landed in #192; container image scan still open
- #176 — Dependency upgrades: graphql-yoga 4→5, Node 20→22 — landed in #194
⚪ P2 — GA polish / hygiene
- #177 — Verify error masking (no DB error leakage) — landed in #195
- #178 — Cut 1.0.0 + schema stability / deprecation policy — landed in #198
- #179 — Reference deployment artifacts + resource limits — landed in #196
- #180 — Runbook / SLOs / capacity + replica-failover semantics — landed in #197
🧪 Test coverage
- #181 — Audit + live integration tests for devnet / mainnet / mesa — landed in #199
Status
14 of 18 items are done. The four open items are all P1: #172 (#190) and #174 (#193) are open PRs rebased and mergeable; #173 and #175 are partly landed and now track only their residual scope.
Sequencing
P0 first (makes "publicly reachable" safe), then P1 (operability), then P2 + the 1.0.0 cut. Each item is its own issue so we can fill them in slowly.
Epic generated from a production-readiness analysis of the repo at main.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the remaining P1 work in #172–#175 and the referenced PRs #190, #193, #191, and #192. The epic is done when the four open or residual items are completed and the production-readiness checklist for the public GraphQL endpoint is closed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- graphql, postgres, typescript
- Domain
- api, backend, databases, devops, observability, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100