Mute list fallback to cache + retry on region change if still pending#5269
Mute list fallback to cache + retry on region change if still pending#5269DarlCat wants to merge 1 commit intosecondlife:developfrom
Conversation
- fall back to the cached mute list on request timeout or transfer failure so the list never stays empty if we can help it - retry mute list requests on region change with a short cooldwn to avoid being too noisy, if still in timeout window - cancel pending timeout once the list loads to stop unnecessary potential fallback behaviors - refesh the blocked list UI when a cached or deferred load populates it - notify the user of a forced cache fallback because recent changes may be missing Signed-off-by: Darl <me@darl.cat>
| return; | ||
| } | ||
| s_notified = true; | ||
| LLNotificationsUtil::add("MuteListFallbackCache"); |
There was a problem hiding this comment.
I don't think this should be shown to a user. At least in some cases it's a bug that needs to be fixed server side in others viewer should rerequest.
If viewer timeouts, got an empty list or errors getting the list, you probably can do something about it via MuteCRC field. But I agree that if something got wrong we at least should get the data from cache.
Or read cache first (issues with this approach if outdated?), mark as 'no send', apply server response on top...
P.S. Related: #4267
There was a problem hiding this comment.
I don't think this should be shown to a user.
I added a notification because I felt the user impact of potentially missing recent uncached mutes that the server could be aware of that we are not could be highly disruptive to the user. In a perfect world they should never see the notification because the replies to MuteListRequest are expected to arrive, but the user complaints about this I have seen are describing a great level of distress over harassment the mute list should prevent.
The notification will absolutely be removed if it's decided to not be acceptable. I felt it was appropriate at the time given the potential impact of missing mutes.
If viewer timeouts, got an empty list or errors getting the list, you probably can do something about it via MuteCRC field. But I agree that if something got wrong we at least should get the data from cache.
That is my thought, because for some unknown reason these messages are being lost or remain unsent at random for some users.
Or read cache first (issues with this approach if outdated?), mark as 'no send', apply server response on top...
The UpdateMuteListEntry and RemoveMuteListEntry messages both refer to mutes by their ID or name, so as far as I can tell there should be no negative impact on the server mute list if the user moves forward with a session of adding/removing mutes based on their cached copy. The client would just be missing the local record of what is on the server.
What I considered when deciding not to go for the cached data first, then layer on the server once (if?) we get it was the merging logic. If we were to load from cache first and later learn of a newer server version, it is not guaranteed to be reconcilable with what we have in our cache.
For merging the server list with the cached list, the assumptions I would have to make could potentially result in unintended re-mutes or unintended unmutes based on which we determine to be the correct state of a mute that is present vs not or different in one list compared to the other.
I was very anxious to repeatedly request a mute list from the region because I do not want to generate undue load with loops. There are two timeouts/cooldowns in place within my PR
- The existing conceptual 30 second timeout, after which for the duration of the session I completely rely on the cached mute list and stop caring about what the server may ultimately come back with to avoid merging or recreating the mute list, and stop any effort to re-request an update
- The 5 second cooldown between
MuteListRequestdispatch attempts, which can be triggered by region change. This was to prevent asking every region an agent may be passing through for a mute list that they may not stay around long enough to receive.
There was a problem hiding this comment.
because for some unknown reason these messages are being lost or remain unsent at random for some users.
I will create a server ticket for that. I know at least one case with a repro where server isn't responding yet should.
There was a problem hiding this comment.
I was very anxious to repeatedly request a mute list from the region because I do not want to generate undue load with loops.
Makes sense. But region change can end up requesting indefinetely either way. Better add some kind of retry limit there.
There was a problem hiding this comment.
because for some unknown reason these messages are being lost
SendReliable supports callbacks. Might be possible to refine this by detecting send failures to log better and to rerequest on failures.
There was a problem hiding this comment.
Pull request overview
This pull request implements fallback mechanisms for mute list loading to improve reliability when simulator messages are lost or delayed during login. The changes add timeout-based cache fallback, retry logic on region changes, and better UI updates when cached data is used.
Changes:
- Added timeout mechanism (30 seconds) to fall back to cached mute list if server request doesn't respond
- Implemented retry logic on region changes with 5-second cooldown to avoid request spam
- Added user notification when falling back to cached data
- Enhanced blocked list UI to refresh when cached or deferred data loads
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| indra/newview/skins/default/xui/en/notifications.xml | Added new notification to inform users when cached mute list is used due to server communication issues |
| indra/newview/llmutelist.h | Added timer management, region change callback, and helper methods to support timeout and retry mechanisms |
| indra/newview/llmutelist.cpp | Implemented timeout handling, cache fallback logic, region change retry, timer cleanup, and refactored cache loading |
| indra/newview/llblocklist.h | Updated method signatures with override keywords for better code quality |
| indra/newview/llblocklist.cpp | Implemented onChange() to detect and handle transitions from empty to populated mute list |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| mShouldAddAll = true; | ||
| mActionType = NONE; | ||
| setDirty(true); | ||
| } |
There was a problem hiding this comment.
The onChange() implementation only handles the case where mMuteListSize transitions from 0 to a positive value. If the mute list size changes in any other way through a batch operation (e.g., from 10 to 15 items when cache loads), the UI will not update because the condition on line 88 will be false. Consider updating mMuteListSize at the end of this method or triggering a refresh whenever current_size != mMuteListSize, not just when transitioning from zero.
| mShouldAddAll = true; | |
| mActionType = NONE; | |
| setDirty(true); | |
| } | |
| // Initial population of the mute list: add all existing entries. | |
| mShouldAddAll = true; | |
| mActionType = NONE; | |
| } | |
| // The mute list size has changed; mark the UI as needing refresh | |
| // and update our cached size so future comparisons are correct. | |
| setDirty(true); | |
| mMuteListSize = current_size; |
|
@Geenz What do you think about this one? P.S. Created a server ticket, because that's where the problem comes from at least in some cases https://github.com/secondlife/server/issues/2305 |
|
I plan to be making an update to this PR that addresses feedback given, so unless the exact state it's in now becomes satisfactory it may be best set to draft. There's excellent feedback here, and my mind is personally already changed that a notification isn't ideal for this when we can fail-safe and never alert or scare the user. I'm working on an implementation for this PR that expands the state machine design already in place to integrate graceful retry logic, and use of the cache as a starting point rather than an eventual fallback. This approach makes a notification unnecessary in my opinion. |
|
Thank you! Moved to draft. |
2 participants
Description
This PR aims to reduce user impact of unsent or dropped simulator messages during login regarding the mute list. The current behavior when this occurs is to have an empty mute list, and not fallback to cache even if it is present. This PR updates this behavior in the following ways:
Related Issues
https://feedback.secondlife.com/bug-reports/p/block-list-empties
Checklist
Please ensure the following before requesting review:
Additional Notes
I've tested this locally with success, however I am not able to test all platforms. Bugs based on packet loss are a challenge to reproduce so my testing was based on artificially induced drops. I do not think that this is a perfect solution as the existing comments in code suggest this would ideally be moved to a capability, but this is intended keep people from too much hardship until that more comprehensive effort can be prioritized.
Very much open to feedback and willing to make reasonable requested changes.