Pause crawls instead of stopping when quotas are reached or archiving is disabled #2997
Conversation
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
Needs to be tested, just pushing as-is so that I can pick it up next week. There's an issue in local testing where crawls sometimes appear to be twice as big as they really are, which is making Browsertrix think the storage quota is reached prematurely. I haven't yet pinned down the cause of this and it seems intermittent.
tw4l
force-pushed
the
issue-2957-pause-crawl-on-quota-reached
branch
from
f7568a3 to
217e935
Compare
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.
Fixes #2957
Full backend and frontend implementation, with a new email notification to org admins when a crawl is paused because an org quota has been reached.
Backend changes
paused_storage_quota_reached,paused_time_quota_reached,paused_org_readonlybytesStoredabove the storage quotaFrontend changes
Needs attention
status.filesAddedSize, then added again tostats.size(see TODO comment in crawl operator code) again, which effectively doubles thestats.sizeof the crawl and results in the crawl seeming larger than it is. I've attempted a few solutions for this such as not addingstatus.filesAddedSizetostats.sizeis the crawl is pausing, but no solution I've attempted has consistently resolved the issue without introducing other side effects. I think this may have a downstream effect at times on the storage quota check inis_crawl_stopping- I have that check now subtracting the size of already-uploaded WACZs from the active crawl size that's used in checking whether active crawls will put the org over its storage quota, but if it's inconsistent whether the previously-uploaded WACZs are included instats.sizeor not, the check might become inaccurate at times.crawlSuccessfulCount- this change could use a second pair of eyes to make sure it makes sense - I'm not entirely surecrawlSuccessfulCountis intended to mean crawls that ended with a successful state, or just crawls that completed in any form. This field does not appear to be used in the frontend in any form, and might be inconsistent if we switch how it's counted now without a migration, so maybe this is handled better separately?