Repository navigation
feat(status): separate process health from data health - #590
Conversation
/status was excluded from the OpenAPI contract, so nothing described its shape or which values mean unhealthy. Document the full response, report process health and data health as separate fields (data fresh/stale/empty), and make 503 the single paging condition when a network's ingester falls behind STATUS_STALE_AFTER_SECONDS. Co-Authored-By: Codebuff <noreply@codebuff.com>
tsc --noEmit clean vitest 106 files, 1232 passing (up from 102 / 1157) dropped-tests none Four of the eight screened in this group. The other four were held, and the reason is worth stating because it keeps recurring: each one merges cleanly and fails on its own. #590 72 type errors alone, including syntax errors in src/api/rest.ts and src/api/schemas.ts -- "Declaration or statement expected", "Expression expected". Not type mismatches; the file does not parse. #584 3 type errors alone #592 conflicts #595 conflicts Merged together before screening, that group produced 68 failing test files and syntax errors I first mistook for a bad three-way merge. They were not: #590 carries them on its own branch. Screening each PR individually before batching costs one typecheck per PR and saves an hour of bisection, which is the lesson of the day. Claude-Session: https://claude.ai/code/session_01USgemLt4Rnz4SGB1Srf3GB
Miracle656
left a comment
There was a problem hiding this comment.
This does not parse on its own branch. Merged alone against current main, tsc --noEmit gives 72 errors, and the first few are syntax rather than types:
src/api/rest.ts(140,9): error TS1128: Declaration or statement expected
src/api/rest.ts(146,14): error TS1005: ';' expected
src/api/rest.ts(152,5): error TS1109: Expression expected
src/api/schemas.ts(32,2): error TS1109: Expression expected
TS1128 and TS1109 mean the file cannot be read as TypeScript at all — a brace or bracket is unbalanced somewhere above line 140. The other 68 errors are almost certainly downstream of that; fix the syntax and most will go.
I would look for a conflict resolution that kept both sides of a block, or an editor save that lost a closing brace. src/api/rest.ts is the most-edited file in this repository right now — nearly every open PR touches it — so it is the easiest place for that to happen and the hardest place to notice.
Separating process health from data health is a genuinely useful distinction and I want it: "the process is up" and "the data is current" answer different questions, and conflating them is how a service looks healthy while serving stale prices. Please get npx tsc --noEmit clean locally and re-request.
These duplicate work already on main through Divinity-Labs#533 (Divinity-Labs#273). This PR is for Divinity-Labs#275 only.
|
Merged into First, a heads-up about this PR's identity. It is titled "feat(status): separate process health from data health", but the branch now contains the README drift guard — On the content itself This is the right version of the guard, and it landed on the generator that actually shipped. #475 put Two things you got right that are easy to get wrong: CRLF normalisation before comparing. Every other generated-artifact guard in this repo byte-compares, and an identical table with Windows line endings has been reported as drift here before — someone then "fixes" a file that was never wrong. Normalising first is the correct call and worth copying into the other guards. Chaining I verified the guard actually bites rather than trusting it: edited a row by hand → exit 1; restored → exit 0. One fix on merge The drift test did: committed.replace('| GET | `/tvl` |', '| GET | `/tvl-renamed` |')
tsc clean, 1,730 tests pass. |
Summary
Automates the README endpoint table generation using "openapi.yaml" as the single source of truth.
Changes
Closes #275.