AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 37 Monero

fix(shopinbit): back off pollers on error and pause when backgrounded

Public commit record

What the developer wrote

Authored by sneurlax

85/100 · Strong
fix(shopinbit): back off pollers on error and pause when backgrounded

The payment, car-research, and ticket-detail views polled on fixed 15s/30s timers that kept firing at full rate even when a request failed, so a 429 just got ignored and re-provoked. Switch each to a self-scheduling timer that doubles its interval on failure (capped at 120s) and resets on success, and pause polling while the app is backgrounded via WidgetsBindingObserver. Previously swallowed poll errors are now logged.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a bug in Stack Wallet's ShopInBit feature where the app kept asking the server for updates every 15 or 30 seconds, even when the server was already saying 'slow down' (HTTP 429) or the request failed. The fix adds a backoff that doubles the wait time after failures, pauses polling when the app is in the background, and starts logging errors that were previously silently ignored. It is a defensive hardening change, not an active vulnerability being exploited.

Recommended action

Treat as a reliability and minor security hardening fix. No urgent user action is required. Review whether server-side rate limits are also enforced independently of client behavior, and consider centralizing polling/backoff logic to avoid future inconsistencies.

Security signals we found

01

Rate-limit/429 amplification via fixed-interval polling

02

Silent swallowing of poll exceptions removed

03

Background polling continues unnecessarily without lifecycle awareness

04

Exponential backoff added for failure cases

05

No authentication, cryptographic, or input-validation changes observed

Risk score

Why this scored 37/100

Our methodology →
Potential impact 8/30
Exploitability 6/25
Stealth signal 4/15
Affected reach 7/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.