fix: enforce scrape timeout for all runs#2299
Open
adityathebe wants to merge 2 commits into
Open
Conversation
Scheduled scrapes could run without a deadline while manual runs used a separate hardcoded timeout. Add a top-level ScrapeConfig timeout and apply it inside the scraper run path, falling back to scraper.timeout and then 4h so manual, scheduled, and CLI runs share the same behavior.
BenchstatBase: 📊 2 minor regression(s) (all within 5% threshold)
Full benchstat output |
Contributor
WalkthroughThe PR removes the per-call context timeout helper (ScrapeContext.WithTimeout) and instead adds a ScraperSpec.TimeoutDuration method that parses a configurable timeout string, applied centrally in scrapers/run.go. Call sites in cmd/run.go and scrapers/run_now.go drop their local timeout logic. JSON/CRD schemas add OpenSearch connection definitions, a scraper timeout field, and an updated repo description. ChangesScraper Timeout Refactor
OpenSearch Connection and Schema Description Updates
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@api/v1/types.go`:
- Around line 118-129: The ScraperSpec.TimeoutDuration helper currently accepts
parsed durations that are zero or negative, which later flow into
ctx.Context.WithTimeout in scrapers/run.go and can cancel scraping immediately.
Update TimeoutDuration to validate the parsed timeout is strictly greater than
zero before returning it, and return an error for "0s" or any negative value.
Keep the existing parsing/error handling in ScraperSpec.TimeoutDuration and use
the timeout value check right after duration.ParseDuration.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 1954b355-4fa1-4fda-b4b0-8d73e20fda41
📒 Files selected for processing (11)
api/context.goapi/v1/timeout_test.goapi/v1/types.gochart/crds/configs.flanksource.com_scrapeconfigs.yamlcmd/run.goconfig/schemas/config_exec.schema.jsonconfig/schemas/config_github.schema.jsonconfig/schemas/config_playwright.schema.jsonconfig/schemas/scrape_config.schema.jsonscrapers/run.goscrapers/run_now.go
💤 Files with no reviewable changes (1)
- api/context.go
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.
CloudTrail scrapes could run indefinitely when triggered by the scheduled job path.
The manual run path had its own hardcoded timeout, but scheduled runs did not consistently apply a scrape deadline. Add a top-level ScrapeConfig timeout and enforce it centrally when scrapers run, falling back to the scraper.timeout property and then 4h.
Manual, scheduled, and CLI runs now share the same timeout behavior.
Summary by CodeRabbit
New Features
30mand1d.Bug Fixes
Documentation