archetech / archon / 30718841579

91%

main: 94%

Pull #823

github

fix(gatekeeper): store and return block time as a number in both ports

The sqlite backend declared `time TEXT NOT NULL` while BlockInfo.time is
typed `number`, so the value was stringified across the SQL boundary.
TypeScript could not catch it: the row is type-asserted, not validated.
json, redis and mongo all round-trip it as a number, so sqlite was the
only backend out of step.

The Rust port had the same schema and a worse symptom. add_block
stringified the value, get_block read it back with row.get::<_, String>,
and the anchoring metadata then does:

    "timeISO": block.get("time").and_then(Value::as_u64)

which yields None for a JSON string — so `timeISO` was ALWAYS null on the
sqlite backend, while redis and mongo populated it. That is user-visible
DID resolution metadata missing on one backend.

Both ports now declare the column INTEGER and coerce on read. The read
coercion is the load-bearing part: `CREATE TABLE IF NOT EXISTS` leaves
databases created earlier on the old TEXT affinity, so a schema-only
change would fix new deployments and silently leave existing ones broken.
Rust parses a legacy TEXT value back to an integer for the same reason.

The existing Rust test asserted the defect — it expected `"time": ""` for
a block posted without a time. That now reads 0: a number, consistent
with BlockInfo.time and with the `txns` fallback beside it.

Verified: 1,892 JS tests, the full Rust gatekeeper suite (48 tests across
10 binaries), eslint and cargo check clean. The TS regression test drives
a row written under the old TEXT affinity to prove existing databases are
repaired, not just new ones.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

3409 of 4060 branches covered (83.97%)

Branch coverage included in aggregate %.

7985 of 8510 relevant lines covered (93.83%)

668.86 hits per line