mayinab froze randomly when navigating subtopics (7 tries to find it)

this was the most stubborn bug ive ever faced in mayinab.

the symptom: when navigating fast between subjects and subtopics, the app froze permanently. wasnt lag. was a full freeze. had to kill the process and reopen. (ꐦ°᷄д°᷅)

and the bug was intermitent. worked fine for a while, then out of nowhere it froze. impossible to reproduce consistently, unless u did a stress test with rapid clicks.

the 6 tries that failed

i spent DAYS thinking it was GptMarkdown / flutter_math_fork (bc they had given me headaches before with the LaTeX bug). i tried everything:

try 4 was the most frustrating. the debounce just slowed the loop to ~30Hz instead of killing it. every 32ms a setState ran, the list rebuilt with slightly different sizes, the observer flipped again... infinite loop but slower. still infinite tho. ¯\_(ツ)_/¯

the root cause: ChatScrollObserver

after 6 fails i finally stopped blaming markdown and went to read the source code of ChatScrollObserver from the scrollview_observer package. and there was the monster.

three interlinked mechanisms caused the freeze:

1. perpetual chain of addPostFrameCallback

the ChatScrollObserver constructor schedules observeSwitchShrinkWrap(). that method, internally, schedules another addPostFrameCallback. reattach() calls innerReattachCallBack which fires _setupSliverController(), which schedules yet another callback. result: infinite callback loop that never stops. its a runaway train.

// the constructor already starts scheduling chaos
ChatScrollObserver(this.observerController) {
  WidgetsBinding.instance.addPostFrameCallback((timeStamp) {
    observeSwitchShrinkWrap(); // ← schedules ANOTHER callback internally
  });
}

2. standby() forces re-layout without position correction

standby() calls viewport.markNeedsLayout() to force re-layout, but without ChatObserverClampingScrollPhysics (which i never configured on the ListView), position correction is never executed. markNeedsLayout() just causes unnecessary work that feeds the observation loop.

3. shrinkWrap mismatch

ChatScrollObserver starts with innerIsShrinkWrap = true, but my ListView.builder had shrinkWrap: false hardcoded. observeSwitchShrinkWrap detects the difference, flips to false, calls reattach(), which schedules new callbacks... and the cycle repeats forever. ヽ(°〇°)ﾉ

the fix (try 7)

i removed ChatScrollObserver entirely. no half measures.

// BEFORE (buggy):
_chatScrollObserver = ChatScrollObserver(_observerController)
  ..fixedPositionOffset = 5;

// AFTER (working):
// nothing. removed. bye bye.

i kept the pure ListObserverController + ListViewObserver (bc those are used for jumpTo, animateTo and pagination via onObserve). they dont have the crazy side effects of the chat wrapper.

bonus: bugs found along the way

while investigating the freeze, i found 3 more hidden bugs that were contributing to the chaos:

results

lesson learned

ler em português →