Mayinab travava do nada ao navegar entre subtopics (7 tentativas até achar)

esse foi o bug mais teimoso que ja enfrentei no Mayinab.

o sintoma: ao navegar rapido entre subjects e subtopics, o app congelava permanentemente. nao era lag. era freeze. tinha q matar o processo e reabrir. (ꐦ°᷄д°᷅)

e o bug era intermitente. funcionava de boa por um tempo, ai do nada travava. impossivel de reproduzir consistentemente, a nao ser com stress test de cliques rapidos.

As 6 Tentativas que Falharam

eu passei DIAS achando q era o GptMarkdown / flutter_math_fork (pq ja tinham me dado dor de cabeça antes com o bug do LaTeX). tentei de tudo:

a tentativa 4 foi a mais frustrante. o debounce so atrasava o loop pra ~30Hz em vez de eliminar. cada 32ms um setState rodava, a lista reconstruia com tamanhos levemente diferentes, o observer flipava de novo... loop infinito mais lento, mas ainda infinito. ¯\_(ツ)_/¯

A Causa Raiz: ChatScrollObserver

depois de 6 fracassos eu finalmente parei de culpar o markdown e fui ler o codigo fonte do ChatScrollObserver do pacote scrollview_observer. e la tava o monstro.

tres mecanismos interligados causavam o freeze:

1. Cadeia perpetua de addPostFrameCallback

o construtor do ChatScrollObserver agenda observeSwitchShrinkWrap(). esse metodo, internamente, agenda outro addPostFrameCallback. o reattach() chama innerReattachCallBack que dispara _setupSliverController(), que agenda mais um callback. resultado: loop infinito de callbacks que nunca para. eh um trem desgovernado.

// o construtor ja comeca agendando o caos
ChatScrollObserver(this.observerController) {
  WidgetsBinding.instance.addPostFrameCallback((timeStamp) {
    observeSwitchShrinkWrap(); // ← agenda OUTRO callback interno
  });
}

2. standby() força re-layout sem correcao de posicao

o standby() chama viewport.markNeedsLayout() pra forcar re-layout, mas sem ChatObserverClampingScrollPhysics (que eu nunca configurei no ListView), a correcao de posicao nunca eh executada. o markNeedsLayout() so causa trabalho desnecessario que alimenta o loop de observacao.

3. Mismatch de shrinkWrap

ChatScrollObserver comeca com innerIsShrinkWrap = true, mas meu ListView.builder tinha shrinkWrap: false hardcoded. o observeSwitchShrinkWrap detecta a diferenca, flipa pra false, chama reattach(), que agenda novos callbacks... e o ciclo se repete pra sempre. ヽ(°〇°)ﾉ

A Solucao (Tentativa 7)

removi o ChatScrollObserver inteiramente. sem meias medidas.

// ANTES (bugado):
_chatScrollObserver = ChatScrollObserver(_observerController)
  ..fixedPositionOffset = 5;

// DEPOIS (funcional):
// nada. removido. bye bye.

mantive o ListObserverController + ListViewObserver puros (pq esses sao usados pra jumpTo, animateTo e paginacao via onObserve). eles nao tem os side effects malucos do wrapper de chat.

Bonus: Bugs que achei no caminho

enquanto investigava o freeze, achei mais 3 bugs escondidos q contribuiam pro caos:

Resultado

Licao aprendida