feat: Twitter UsageCapExceeded flag-file early-exit#2
feat: Twitter UsageCapExceeded flag-file early-exit#2ClawdiaETH wants to merge 2 commits intomainfrom
Conversation
When Twitter monthly cap is hit, apiGet() now: - Detects UsageCapExceeded (or 429) in the API error response - Writes ~/clawd/data/twitter-cap-exceeded.flag with expiry = 1st of next month - Clears the flag on any successful API response main() now checks the flag at startup (before DB connection or any API call) and exits immediately with a single warning log. This saves DB connections and wasted exec cycles on every 15-min cron tick when the cap is guaranteed to be exceeded until month rollover. Fixes: backlog [NEXT] 'Add UsageCapExceeded early-exit to spellblock-mentions.mjs' Context: Cap hit 2026-02-24 ~19:40 CT; resets ~2026-03-01
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
PR SummaryLow Risk Overview
Written by Cursor Bugbot for commit be59928. This will update automatically on new commits. Configure here. |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Remove the '|| res.status === 429' fallback from the cap detection logic at both lines 122 and 135. Twitter returns HTTP 429 for both per-window rate limits (15-min cooldown) and monthly usage caps. Only the UsageCapExceeded string in the response body reliably identifies the monthly cap. The previous code would incorrectly disable the bot for up to 30 days when hitting a routine rate limit.
|
Bugbot Autofix prepared fixes for 1 of the 1 bugs found in the latest run.
|
2 participants
What
Adds a flag-file guard so
spellblock-mentions.mjsexits immediately when the Twitter monthly usage cap is hit, instead of burning DB connections and exec cycles on every cron tick.Why
Twitter monthly cap was hit 2026-02-24 ~19:40 CT. Every 15-min cron since has been a guaranteed API failure until cap resets ~2026-03-01. This fix makes those runs near-instantaneous no-ops.
How
~/clawd/data/twitter-cap-exceeded.flag— shared flag file (ISO expiry timestamp, 1st of next month UTC)isCapFlagActive()runs before DB connection or any API call. If active → single log line + return.apiGet()detectsUsageCapExceededin response body (or HTTP 429) → callswriteCapFlag()clearCapFlag()runs on every successful API responseFlag file spec
Companion change
Same guard added to
mention-screener.pyinstarl3xx/clawd(local branchfeat/twitter-cap-exceeded-guard— awaiting push auth from Jake).Verified
Flag logic smoke-tested: