Examples: self-development TaskSpawners use aggressive 1m pollInterval without explanation
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 331
- Forks
- 40
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 70
Description
Problem
Both self-development examples (axon-workers.yaml and axon-fake-user.yaml) use pollInterval: 1m, which polls GitHub every minute. This is:
- Much more aggressive than the API default of
5m - Not explained in comments or documentation
- Could lead to GitHub API rate limiting for users who copy the examples
- May not be necessary for most use cases
Current state
# self-development/axon-workers.yaml:65
pollInterval: 1m
# self-development/axon-fake-user.yaml:67
pollInterval: 1m
No comment or documentation explains why 1 minute polling is needed.
Why this matters
- Rate limiting risk: GitHub API has rate limits. Polling every minute for all issues could hit limits on active repositories
- Resource usage: More frequent polling means more controller work and API calls
- Copy-paste confusion: New users copying these examples won't know this is intentionally aggressive for Axon's own development
- Misleading defaults: Users might think 1m is the recommended interval when 5m is actually the default
Suggested fixes
Option 1: Add explanatory comments
# pollInterval: 1m for responsive self-development loop
# For production use, consider 5m (default) or longer to reduce API calls
pollInterval: 1m
Option 2: Use the default and explain in README
Remove the pollInterval lines and add to self-development/README.md:
## Customization
### Poll Interval
These examples use the default 5m poll interval. For more responsive development,
you can set `pollInterval: 1m`, but be aware of GitHub API rate limits.
Option 3: Make it configurable
Document in the README that users should adjust based on their needs:
### Recommended pollInterval values:
- Active development: 1-2m (watch for rate limits)
- Production monitoring: 5-10m
- Low-traffic repos: 15-30m
Recommendation
Option 1 is simplest - just add a comment explaining the intentional trade-off. This keeps the examples as-is while educating users.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with self-development/axon-workers.yaml:65 and self-development/axon-fake-user.yaml:67, then compare their 1m pollInterval with the documented 5m API default. Add explanatory comments about the intentional self-development trade-off and rate-limit risk, and verify both examples clearly distinguish this setting from the recommended default.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 58/100