dcf3814446
Chacun reproduit avant d'etre corrige, chacun epingle par un test qui echoue si la correction est retiree. 1. Une barriere pouvait survivre a la tentative qui l'avait produite. `getSyncState` repondait `"synced"` sur le seul `barrierCrossed`, alors que son propre commentaire disait « sur le canal qui tient MAINTENANT » : `reportSetupFailure` efface `establishing` et laisse `lastState`, donc un `doc_subscribe` qui poussait un `State` puis echouait laissait une autorite - et `noRowsMeansAbsent` prend une lecture a zero ligne pour une absence definitive. Le registre precedent repondait `"timed-out"` la ; strict est la lecture de cette famille, son cout est la latence, jamais la perte. 2. `release` ne repondait pas « est-ce que j'ecoute encore ». `resetDocSubscriptions()` largue les auditeurs et supprime l'entree sans rien dire, donc le handle continuait de paraitre vivant ; si autre chose souscrivait d'abord au meme document, le court-circuit sautait l'ouverture due et le document restait tenu par un auditeur libre de partir. Le fan-out numerote desormais ses incarnations, et l'ouverture compare. 3. Une tentative sans reponse TIENT quand meme. Elle ne comptait pas, si bien que chaque lecture d'un document dont le `doc_subscribe` ne repond jamais repayait le repli borne - 8 s en production, sur le chemin de la lecture ancree. Un second `doc_subscribe` est de toute facon impossible tant qu'un est en vol, donc la tentative fraiche n'achetait rien. Les trois questions sont maintenant une fonction nommee, `stillStanding`, et chacune est posee a qui detient la reponse.