Tusky notification-refactor branch got confused about filters, then crashed

[mcclure]

Detailed description

This morning I woke up and scrolled through my Tusky notifications. Because of Arguments, I had an unusually large number of notifications. I was finding it hard to see the replies among the boosts, so I tapped "filter" to hide the boosts and favs. To my surprise, "favs" and "boosts" were already disabled in the filter settings, although favs and boosts were definitely visible. Experimentally, I tapped "Apply" without making any changes. The app crashed ("this app has stopped"). Afterward I found this stack trace in my logcat:

tusky-crash-snip-2024-05-09.txt

On rebooting, the inconsistent state (boosts and favs visible, but unchecked in filter dropdown) persisted. "Refreshing" (IE dragging down from top) did not fix the visibility states as it sometimes does. Clicking "Apply" did not fix the visibility states (although also, it did not cause another crash). Checking "boosts" and "Favs" and hitting apply, then unchecking and hitting apply again, did fix the visibility states.

Steps to reproduce the problem

No known reproduction

Debug information

5ba10f2d2067 (non-final commit from notification refactor branch), self-built, greenDebug

[mcclure]

Screenshot of event, note unchecked boosts/favs and visible boost/favs

Note if this issue is not reproduced or resolved by the release of v26 we should close it, due to it being an incomplete revision to start with.

[mcclure]

Yesterday upgraded to a release build of 05c7e7b (develop branch head yesterday). This morning I again reproduced the "boosts and favorites are turned off, but still appearing in the notification column". It may be this is 100% reproducible and you just need to turn off boosts and favs in the filters, make a high-visibility post that will generate diverse notifications, turn off the phone and go to bed. The crash did not reproduce.

Screenshot: