FeelsBadMan

This bug has existed since the inception of favorites and has been reported by many people. Basically syncing settings, in particular "userFavoritesMTTList" from within the settings object, with the server storage is broken, and makes using the favorites feature between multiple devices almost unusable. It seems like when you add or remove a favorite MTT or change any setting, the server storage updates with your new preferences perfectly fine. When your client has settings (with favorites in them) in local storage, which is the case for the desktop and mobile clients, then the client first retrieves the local storage favorites, then it retrieves the server favorites, it detects a discrepancy between server (source) and client (destination) as evidenced by the following log "[CSettings::UpdateMap] source size: 766, destination size: 784", and then it logs "[CRlxNewTicketAwardService::StartService] Settings synced with the server storage". Now, what seems to be happening when your local settings get synced with the server storage is that it can only add or modify keys, but it can't remove keys from "userFavoritesMTTList" and probably same for anything else in the settings object so there might be a reason for it, but it breaks favorites. So what happens in the situation presented above, is that despite the server having only 766 favorites, the client will remain with 784. Now let's say the 766 favorites on the server contain 4 new favorites, now your client will be updated to 788 favorites, the 784 originally in local storage + the 4 new ones but it does not remove any of the ones that are no longer in server storage. In this scenario, as long as you change NOTHING on the client, no favorites, no settings, no table nudges, the server data will still contain the correct 766 and the other device where you have removed the MTTs will continue to be correct with 766. But the moment you change anything to the settings object in your client, including experiencing a table nudge out of your control, both the server and the other device get updated to 788, despite you removing a lot of MTTs on the other device. The fix is pretty obvious, but idk if it has any other problematic ramifications; when syncing the settings object and the local storage with the server storage, just remove the keys from "userFavoritesMTTList" that are no longer present in the server storage, which seems to work fine when updating the server storage. Alternatively, if removing keys causes other problems, just set the value of the key to false when removing, or true when adding, and only display the favorites that have a value of true. You might also ask yourself, why does this psycho have 766 favorited MTTs? Almost all of those are old templates that are impossible to remove as they are not displayed in the client. Surely there will be no issues with an ever expanding settings object with unremovable favorites and table nudges 🤔. It will all probably be fine. The Browser client, due to its lack of persistent local storage (or maybe it's just my browser that doesn't store stuff) is the only one that correctly updates from server storage, but obviously it will also experience similar issues when another device updates the server storage.

When you logout or timeout on desktop or android you end up on this screen: And after a few seconds (or after clicking authentication) you just get redirected to the main website page:

This is a super low priority bug that happens on every platform, desktop, mobile and browser. As you can see in the video, if hands are still being loaded the scroll bar and the contents snaps back to the top with every payload received (similar to the cashgame stakes bug happening now on mobile). And as the default ordering is by time and all the payloads are being placed at the bottom (when default sorted), the scroll bar and the contents should stay put to let the user look through the hands, probably by using an offset to scrollHeight that makes sure to keep the data somewhat in place, with maybe the 1st visible row as an anchor or the center visible row, or maybe you have some other easier method to not have it snap back. Keep in mind that if it's sorted by another column, rows will be added all over the place but IMO it should still stay anchored to the area you are viewing even though rows have been added before after and in the middle. Once the HH list is fully loaded it's no longer a problem, which is why it's super low priority. HH scroll bug.mp4 Also reported by @GR1ZZL3R a month and a half ago:

This is a joint report with @Phlo23 who has been reporting this bug since the dawn of time. While this is a catastrophic bug that has been noticed by quite a few people recently, I wouldn't consider it top priority for the simple fact that you can avoid it during play by just never touching the HH Tab. This bug occurs in the same way on both Desktop app and Mobile app but it's nearly impossible to replicate in browser. What happens is, if go the the HH tab and try to load a date, and before it loads every single hand you decide to change the date or game type because you want to see something else it will completely freeze everything. The freeze also occurs if you open the Promotions tab before all hands loaded, if you go through the months in the calendar as can be seen in @Phlo23's video below, these 2 being less reliably reproduced, more likely on a freshly opened client. And according to @ValueHeavy it can also freeze when you try to load a specific hand before all hands have been received, although I have not been able to reproduce this one. There's probably other ways to trigger this freeze but these are the easiest to isolate and reproduce to include in this report. As you can see in the videos the lobby is fully frozen and can't even be closed, while at the table you can still click buttons and see timebanks running out, BUT there is no information being passed to and from the table (BTW this is the exact way it looked when freezes would happen during play without touching HH, fortunately haven't seen one in a while) However as you can see in the logs videos in the hidden section, the client is still sending and receiving all data just fine, including table actions (don't know about HH stuff as that is not logged, but the "HH received records: x" log never comes anymore so I assume that has successfully stopped). I just can't interact with anything, and can't close the client (Task manager to the rescue). Now you might think, this is only an issue if you play an enormous amount of hands, but that is incorrect, it is just the most reliable way to reproduce, because sometimes it takes a long time to retrieve even a few hands. As you can see in one of the videos it froze after retrieving only 11 hands, and even had a situation where it took 28 seconds to retrieve 0 hands. The time is not necessarily an issue as it's not critical here, but it leads to these freezes happening quite often. Also worth noting that in the 11 hand video all the hands were fully loaded when I tried to change the date, it's like it's doing something else or hangs for a while after loading them, that being a danger period too. I've also added videos of the browser version with devtools open, and as you can see it's nearly impossible to reproduce this bug. You will see the HH filters being frozen sometimes when it takes a particularly long time to receive even a few hands, but the client never freezes completely no matter what I do. The getHands requests get cancelled instantly and with them I assume the callbacks as well that probably cause the freezes in the desktop and mobile client. It's odd that on the non web versions whatever manager object that deals with the HH callbacks ends up freezing something else when it pauses it's own loop, while on web it's acting as it's completely self contained as it should be. Video of freeze happening when changing the date on desktop: Video of the freeze happening when checking promotions on desktop: Video of the freeze even after fully loading a whole 11 hands on desktop: @Phlo23 's freeze when going through the months in the calendar: Mobile freeze when changing the date, app isn't responding and can't be brought back to life like after the popup freeze that was fixed recently: Managed to reproduce Phlo's bug on mobile kind of by accident, once the HH filter buttons get unstuck I change the month without selecting a specific date and it froze:

This has happened ever since more than 2 pinned MTTs got added and it's not a particularly important bug. The last pinned MTT whether it's 3/3 4/4 5/5 ends up getting hidden when you expend one of the other pinned MTTs, and it's always the last one no matter what. Smells like some sort of indexing issue in whatever algorithm deals with sorting the pinned tournaments at the top. The first video shows the bug. The second video shows an empty row appearing instead of the pinned tournament when sorted in reverse by time (can take a few tries to get). Maybe it's a clue. pinned 1.mp4 pinned 2.mp4

I've recorded this bug 5 times in 2 days this week and last week, probably happened more times. The hero chips and parts of the villain are covered by the chip assets that are meant to be the blinds in front of the player, and not on top of the player, something is going wrong with the animation of the chips. Also as can be seen in one of the screenshots, someone making an action does not reset everything as it would for other bugs; the chip assets remain on top of the chip numbers. Steps to reproduce: Play hexapro Have chips covered Fold See that you actually had 0.3BB behind Cry I've attached logs for this bug, it turns out that the tupdate arrives after blinds or deal instead of arriving after the finished winner of the previous hand, every single time the bug occurs, and since these payloads don't come in the right order it doesn't animate it correctly anymore. Whichever solution is being used to deal with the asynchronicity of tupdate doesn't seem to place / execute them in the right order. In addition, spawning the blinds there and then moving them in front seems a bit dangerous, who's to say that even if the asynchronicity issue gets fixed there won't be another issue that will stop that animation from playing out, the location where the blinds spawn should probably be changed as well. Also this might be a coincidence, but in both days 4 out of the 5 occurrences have happened around 16:20 UTC with one happening at 19:40. Maybe worth checking if there was some sort of cronjob running at that time. Won't remove the need to fix the underlying issue, but maybe would fix it temporarily if there really is something there and it isn't just a complete coincidence. Had another one that wasn't in that time frame, so seems less likely now. Added logs, screenshots and a list of the hands that had issues with IDs. These were not the only ones just the ones that I managed to screenshot