Repository navigation
Keep working from a cached crawl list when the index server is down - #139
Merged
Merged
Conversation
Turning "latest" into a crawl ID needs collinfo.json from index.commoncrawl.org. It was cached for six hours and then thrown away: past the TTL the fetch was the only path, so an outage failed the command even though the answer was on disk. index.commoncrawl.org has been refusing connections for three days. With a 19 hour old collinfo in the cache, crawls latest, paths, columnar and download all exited 8, and every one of them reads its actual data from data.commoncrawl.org, which was up the whole time. The columnar example is the quick start printed in ccrawl --help. A failed fetch now falls back to the cached list at any age and says on stderr how old it is and that -c skips the lookup. Common Crawl publishes about six crawls a year, so a day-old list is almost always the list a fresh fetch would return. With no cached copy the run still fails, because guessing is worse than exit 8. Doing this exposed a hole in the exit codes. search keeps going past index pages it cannot read, and a run that read nothing came back as exit 1 whatever went wrong. With the crawl list resolving from cache, a full outage reached that path and stopped reporting itself as one. A run that lost everything to the transport now exits 8; a run where any part of the loss was a status the server sent stays 1, because retrying against a server that is up and refusing is a hot loop. fakecc grew HangupPage to tell those two apart end to end: DeadPage answers 503 and HangupPage drops the connection with no status line. Closes #137
34 tasks done
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
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.
ListCrawlscachedcollinfo.jsonfor six hours and then refused to look at it. Past the TTL the fetch was the only path, so whenindex.commoncrawl.orgwent away the command failed with the answer sitting on disk.Measured during the live outage
index.commoncrawl.orghas refused connections for three days. There was acollinfoentry in the cache from 19 hours ago. Before:After, all four exit 0, each with one line on stderr:
Every one of those reads its real data from
data.commoncrawl.org, which answered 200 throughout. They only touched the index server to turn the wordlatestinto a crawl ID. Thecolumnarone is the quick start printed inccrawl --help.With the cache empty the run still fails, which is the point:
An exit code this uncovered
searchkeeps going past index pages it cannot read, and a run that emitted nothing came back as exit 1 whatever the reason. That path was mostly unreachable during a full outage because the crawl list failed first. Now that the crawl list resolves from cache, a total outage lands there, andsearch 'example.com/*'exited 1 instead of 8, which is the bug #131 fixed coming back through a different door.A run that lost everything to the transport now exits 8. A run where any part of the loss was a status the server sent stays 1: a supervisor that backs off and retries against a server which is up and refusing never stops. Measured live,
search 'example.com/*'is back to exit 8.internal/fakeccgrewHangupPageso a test can tell the two apart end to end.DeadPageanswers 503,HangupPagedrops the connection with no status line.Tests
Four in
ccrawl: the stale fallback resolves and warns with the age in it, no cached copy still fails, a reachable server still beats a stale cache so a new crawl is not hidden behind a cache clear, and the age wording.Three in
cli, end to end against the fake Common Crawl: a hangup on the only page exits 8, a 503 on the only page exits 1, and a run that lost one of each exits 1.Checks
gofmt,go vet,go test ./...,golangci-lint run ./...(0 issues),scripts/docs-drift.sh(406 flag mentions, reference matches the binary),scripts/coverage.sh(ccrawl 66.5, cli 52.7, every package above its floor).Found on the way and filed separately, not fixed here: #138,
--data-dirdoes not move the cache dir although the reference says it does.Closes #137