Stop retrying permanently-LOADING family members without location sharing#221
Stop retrying permanently-LOADING family members without location sharing#221TeroPihlaja wants to merge 2 commits intotimlaing:mainfrom
Conversation
…ring The _initialize_devices() retry loop polled until all family members left the LOADING state or _MAX_REFRESH_RETRIES was exhausted. Family members with location sharing disabled return deviceFetchStatus: LOADING permanently and never resolve, causing the loop to always exhaust all retries and log "Max retries reached when fetching family devices" on every single poll cycle. Replace the fixed-count retry loop with a progress-tracking approach: track which member keys are LOADING between retries and stop as soon as the set stops changing. A member that is still LOADING after a retry with no change will not resolve on further retries — give up on it. Result: - Transient LOADING members (e.g. Sampo's iPhone waking up) still get up to _MAX_REFRESH_RETRIES attempts to resolve - Permanently-LOADING members (e.g. a Mac with location sharing off) cause at most one extra retry before the loop exits cleanly - No more "Max retries reached" log spam on every poll cycle
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughSummary by CodeRabbitBug Fixes
WalkthroughThe Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Pylint (4.0.5)tests/services/test_findmyiphone.pyThanks 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}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@pyicloud/services/findmyiphone.py`:
- Around line 112-136: The loop in findmyiphone.py currently breaks early when
loading_keys == prev_loading_keys, but the failing test expects polling to
continue until _MAX_REFRESH_RETRIES is exhausted (i.e., multiple calls to
self._refresh_client). Remove the early-exit check (the "if loading_keys ==
prev_loading_keys: break" block) so the while loop will keep retrying up to
_MAX_REFRESH_RETRIES, continue updating prev_loading_keys = loading_keys each
iteration, and ensure self._refresh_client(locate=locate) is still called and
retries incremented as before.
🪄 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: 318360d0-6a94-4473-b379-5e16e2fb8623
📒 Files selected for processing (1)
pyicloud/services/findmyiphone.py
|
Thanks for the detailed analysis @coderabbitai. This was already addressed in the follow-up commit d62d0a1 — the |
|
✅ Actions performedFull review triggered. |
|
@coderabbitai review |
|
Only users with a collaborator, contributor, member, or owner role can interact with CodeRabbit. |
1 participant
Problem
The
_initialize_devices()retry loop polls until all family members leave theLOADINGstate or_MAX_REFRESH_RETRIESis exhausted. Family members with location sharing disabled (e.g. a Mac where the user has turned off Share My Location) returndeviceFetchStatus: LOADINGpermanently — they never resolve.This caused the loop to always exhaust all 5 retries and log:
on every single poll cycle, generating constant log noise and unnecessary API calls.
Root cause
The loop only tracked retry count, not whether any progress was made between retries. A permanently-stuck member looks identical to a slow-resolving member until all retries are spent.
The FMIP
membersInfopayload contains no field indicating whether a member has location sharing enabled (onlyaccountFormatter,firstName,lastName,deviceFetchStatus,useAuthWidget,isHSA,appleId), so the member cannot be filtered out by capability.Fix
Track which member keys are
LOADINGbetween retries. If the set ofLOADINGmembers hasn't changed after a retry, those members will not resolve on further retries — stop early.For a transient member that does resolve (e.g. an iPhone waking up):
Result
_MAX_REFRESH_RETRIESattemptsType of change
Co-authored with Claude Sonnet 4.6