fix(health): validate feeds against their own spec version, class failures - #43
Merged
Conversation
…lures The health check validated every feed against spec/v0.4, so publishing a new spec version turned every adopter that hadn't migrated yet into a daily issue: Community Builders' feed is valid 0.3 and its only error was the specVersion const. And a single 20s timeout counted as a failure, which is how eventos.wiki — healthy, but ~50s for half a megabyte — reached the threshold too. Three changes: - Validate against the version the feed declares, compiling from the spec/vN.N directory that published it. Older than the support window (3 minors) is reported, never failed: the feed still works for its consumers. - Class failures before counting them. Transport errors, 429 and 5xx are transient — retried within the run (3 attempts, 60s timeout) and needing 5 of the last 7 runs to open an issue. 4xx, non-JSON and schema errors are deterministic and report after 2. - Publish docs/data/feed-health.json: status, declared version and CORS per feed, so a consumer can see what a feed speaks before subscribing. `updated` tracks the last change, not the last run, so a healthy registry commits nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 30, 2026
This was referenced Aug 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #41. Closes #42.
Both open feed-health issues are false positives, and each one for a different reason:
/specVersion const allowedValue "0.4.0". It declares0.3.0and is otherwise conformant to 0.4 as well. The check hardcodedspec/v0.4, so every adopter that hasn't migrated gets a daily issue the moment a version ships.200and validates. It takes ~51s for 551 KB; the check aborted at 20s.Changes
spec/vN.Ndirectory, chosen by the feed's ownspecVersion. Support window = last 3 minors; older than that is reported assupported: falseand never failed, since the feed still works for its consumers. An unknown version (never published here) is a hard failure — there is no schema to judge it by.alertedflag instead of an exact-equality check on the counter.docs/data/feed-health.json— per feed: status, declared spec version, whether it's in the support window, CORS, failure kind and since.updatedis the date the content last changed, not the run date, so a healthy registry produces no daily commit.Version currency is deliberately never an issue: it is metadata for consumers.
Verification
Ran locally against the real registry and against a synthetic one (invalid feed, 0.1.0 feed, 404, forced timeouts): both real feeds are green, hard failures alert at 2 runs and only once, transient ones don't alert at 2, recovery closes the issue, and state entries are pruned once the window is clean.
npm run validatepasses.🤖 Generated with Claude Code