v2: rewrite

[stegaBOB]

v2 rewrite. Same api/src/... directory layout as master so per-file diffs read in place; #126 stacks on top to flatten, #127 adds /resolve-hash, #128 adds integration tests.

Schema

solana_program_builds (job) + verified_programs (result) merge into one builds table per attempt, with executable_hash, error_message, and a build_status ENUM. verified_programs.on_chain_hash + program_authority merge into one program_state row per program; is_verified is now a derived expression. program_state also gains a pending_reverify flag with no v1 equivalent: the sweep sets it when a program's on-chain hash drifts and drains it by reverifying (capped per cycle). build_logs.program_address renamed program_id; id retyped VARCHAR -> UUID.

Migration runs inline at startup via db.migrate(), idempotent. It copies the v1 data into the new tables but retains them -- the drop is deferred to a follow-up so the cutover stays reversible (a bad deploy can be rolled back by redeploying the v1 binary instead of restoring from backup). See the deploy note at the end of 0001_init.sql.

Runtime

/status/{program_id} was Redis-cached (5min TTL) with a per-request RPC call to fetch program authority on cache miss. v2 caches in-process via moka (invalidated on every write) and is DB-only at request time. One RpcClient, no rotation; rpc_manager.rs gone.

State mutation moves off the read path entirely. v1's check_is_verified spawned reverify_program in the background on hash mismatch — a full solana-verify Docker build kicked off from a read endpoint. v2's check_is_verified is strictly read-only; rebuilds fire from write paths and the background sweep, never from a read:

• /pda webhook: refetch hash, unverify if changed, rebuild against fresh PDA params.
• /unverify webhook: record new hash, no rebuild (PDA still points at old commit).
• Sweep (default 5min): refreshes program_state via batched getMultipleAccounts, and reverifies programs whose on-chain hash drifted (capped per cycle, skipping params already built) -- the backstop for upgrades a webhook missed.
• /verify-with-signer: manual fallback when a webhook is missed and the developer notices stale /status.

Trade-off: between a missed webhook and the next sweep tick, /status can show is_verified=true against stale metadata, bounded by sweep_interval_seconds -- the sweep then reverifies the drifted program and self-heals. Previous behavior had the inverse trade-off: every drifted-program cache miss triggered a Docker build whether anyone needed it or not.

Other

• sqlx in place of Diesel; solana-sdk umbrella -> split crates.
• Config + RPC injected via AppState instead of global Lazys.
• Rust 1.93 -> 1.94, axum 0.6 -> 0.8.
• Existing deploys migrate by deploying v2 -- no db-init container. Migrations run at startup, so take a DB backup and deploy in a maintenance window; the v1 tables are kept for rollback and dropped via a manual follow-up once v2 is healthy.

Perf

Local bench, 336 seeded programs, 4-cores, rate limits dropped.

/status/{program_id} warm path:

concurrency	legacy (Redis hit)	v2 (moka hit)
100	~39k rps, p50=2.4ms	~57k rps, p50=1.6ms
500	~36k rps, p50=13ms	~49k rps, p50=10ms
1000	~27k rps, p50=36ms	~47k rps, p50=20ms

/verified-programs-status: v1 timed out at 60s+ (per-program fan-out); v2 ~5ms.
/status cold path: v2 ~218ms; v1 worst case seconds.

[meumar-osec]

0001_init migrates the v1 data and then drops the old tables. The problem is that if something breaks, we’d be restoring from backup instead of just rolling back the binary, and migrations now run automatically at app startup. Can we add a short deploy note (backup first, maintenance window)? Confirm this has been tested against a prod snapshot?

[meumar-osec]

It’d be good to have at least some tests for the migration path (v1 -> v2) and a few /status + helius /unverify cases, since the current CI is mostly cargo test on a dummy DB and may not catch regressions from this rewrite.

[stegaBOB]

@meumar-osec updated the PR descriptions and opened the remaining PRs in the stack (#126, #127 , #128). They're still targeting main in order to get the CI to run properly.

I updated the migration to retain the old tables instead of deleting, so worst case we should be able to rollback still. I also added a bunch of integration tests in #128 , including for the migration itself. Let me know if theres anything else you'd like to change! I'd be happy to hop in a call and walk you through the changes if you'd like too.