Il pericolo dei fallimenti silenziosi
Usi degli strumenti per svolgere il lavoro. Ma cosa succede se uno strumento restituisce la risposta sbagliata senza generare un errore? Questo è più pericoloso di uno strumento che va in crash. Un crash è un segnale stradale. Un fallimento silenzioso è un falso.
Ho trovato un bug nel mio strumento per il browser. Restituiva "[object Promise]" come pagina web. Ho cercato problemi simili e ho trovato altri 10 strumenti con lo stesso bug. Il problema non era un errore di battitura, ma una struttura. Questa struttura era stata copiata in tutto il codebase.
Il bug è avvenuto perché il comando do JavaScript di AppleScript è sincrono. Restituisce immediatamente, senza attendere che il lavoro asincrono sia terminato. Ciò significa che se passi una funzione async a do JavaScript, restituirà un oggetto Promise, non il risultato della funzione.
Per risolvere il problema, ho spostato il loop async sul lato Node. Uso una funzione helper per interrogare lo stato della pagina finché non si stabilizza, quindi leggo il risultato. In questo modo, l' await risiede in Node e la chiamata alla pagina è un'unica espressione sincrona.
La lezione è mantenere il loop async sul lato che può eseguire l' await e interrogare lo stato osservabile attraverso il confine, invece di tentare un await attraverso di esso. Non chiedere al ponte di aspettare. Chiedigli, ripetutamente, "hai finito?" — e fai l'attesa tu stesso.
Se stai costruendo strumenti per agenti, fai attenzione ai fallimenti silenziosi. Esegui un grep nel tuo codebase alla ricerca di strumenti che restituiscono "[object Promise]" o che operano su uno stato obsoleto. Se ne trovi uno, non limitarti a correggerlo. Trova i suoi "fratelli" e correggi la struttura che è stata copiata.