The Missing Log Proves Nothing
Order 42 failed at checkout. The total was BRL 129, and no integration response was recorded. Support’s proposed explanation was simple: the integration had never been called.
That explanation turned out to fit this attempt. The empty response log was not what established it.
The Incident Is the Prompt followed an exception to an input and type mismatch. One Click, Two Orders examined repeated processing of a purchase intention. This final case asks how much an absent event can tell us.
The setting is the same Oracle APEX laboratory: synthetic purchases, deliberate faults and a simulated delivery integration. App 107 was already deployed. On September 27, 2026, I tested the buyer flow in the browser, completing a control purchase and reproducing the failed checkout below while preserving earlier orders.
Figure 1. The buyer symptom in the deployed application.
Start with the incident
I opened a fresh Codex conversation in VS Code with the complaint, the screenshot, Order 42, a one-hour UTC window and the permitted read-only interfaces. I kept preparation details and package bodies outside the initial workspace so that the investigation would start from the incident. The screenshots below come from that session.
The first attempt failed before any evidence query: Codex treated BF_MCP_RO as a saved SQLcl connection name. I corrected the connection instructions to use the configured evidence connector. Codex then verified the effective database identity as BF_MCP_RO and confirmed UTC for the session and database. I kept the failed attempt and correction in the session record.
Figure 2. The separate conversation began with the incident and read-only boundaries.
Find something that did happen
The health view returned Order 42 in ERROR, with one error and zero integration records. The timeline supplied the useful part: six events for the attempt, including a missing delivery account, validation, an exception and the final error state.
| UTC time on September 27 | Recorded evidence |
|---|---|
| 17:14:58.561285 | Processing started; deliveryAccountPresent:"N" |
| 17:14:58.562886 | Delivery validation entered |
| 17:14:58.565973 | ORA-20071: Delivery account is required; BF_ORDER_PKG, line 103 |
| 17:14:58.580555 | Processing stopped in ERROR |
Codex broadened the lookup within the same hour to the correlation or APEX session. That returned 16 events, including a successful dispatch and response for Order 41, under a different correlation. Session identity alone would have mixed two purchases. The incident bundle returned the same six Order 42 events; it was another presentation of related data, not independent proof of complete logging.
At this point, Codex described a validation failure before any recorded dispatch and requested the relevant source. It did not treat the zero count as proof that execution never reached the integration path.
Figure 3. Positive error evidence, checked time bounds and separate correlations narrowed the explanation.
Connect the backtrace to the code
I provided the requested package excerpts from the installed source I had captured before the incident and compared with the public revision. In BF_ORDER_PKG, body line 103 raises exactly this exception when the delivery account is null. Request preparation follows at line 105; simulated dispatch and response recording follow at lines 107–109.
The exception handler records the error, commits the order’s ERROR state and re-raises. The checkout caller marks the checkout failed and re-raises as well. Neither shown exception path resumes dispatch.
That supports a bounded conclusion: this observed attempt stopped during delivery validation before reaching the simulated integration path. It does not establish what an unrelated external service received. This package writes a synthetic response; it makes no external HTTP request in the supplied path.
Figure 4. Source inspection turns the earlier hypothesis into a supported conclusion for this attempt.
The source also explains why missing logs remain weak evidence on their own. The logger uses autonomous transactions and commits its writes, but suppresses its own exceptions. A normal caller rollback would not erase a successfully committed log entry; a failed logging operation can still leave a gap. Logger failure and retention were considered alternatives, not reproduced experiments.
I did not establish why the account was missing upstream. For the package comparison, I used the installed-source capture from before the incident. The view definitions I provided came from the identified public revision; I did not reverify their deployed DDL during this session. These limits remain part of the conclusion.
A procedure to reuse
Preserve the symptom and order reference. Verify the read-only identity, timestamp types, timezone and query bounds. Keep correlations separate even when requests share a session. Look for the last positively established execution point, then request the source needed to interpret it.
If only an empty log remains, leave the diagnosis unresolved and identify the missing evidence: receiver records, retention history, logger behavior or the deployed control flow. Avoid replaying a business operation just to investigate it.
Codex helped me check correlations and identify the source needed to support the diagnosis. I prepared the incident, corrected the connection instructions and provided the requested code. I did not measure time saved against a manual investigation.
Technical reference
I used BF_MCP_RO through the evidence connector, with the permitted health/timeline views and read-only BF_INCIDENT_PKG interface. Evidence queries selected September 27, 2026, 17:00 inclusive to 18:00 exclusive UTC, with caps of 100 rows or fewer. The general laboratory boundary is at most seven days and 500 rows.
A subtlety emerged from the supplied view source: the health query’s time predicate bounds the selected order, while its integration and error counters aggregate stored rows by order without an internal time filter. Timeline events were explicitly bounded. Also, DUPLICATE_ORDER_COUNT=1 includes the order itself; it does not mean one additional duplicate.
Read the order package, logger, views and query templates at the inspected code revision. Database body line numbers differ from whole-file line numbers.
The reproduction guide describes an isolated installation and the buyer portal. For preparation, I selected the deterministic case administratively and restored RANDOM. During the investigation, I used read-only evidence without retrying orders or changing data. Public source exposes deliberate fault preparation, so this is not a blind experiment.
I tested desktop checkout, inspected the narrow layout, checked navigation and compared cart contents between normal and private Safari sessions. Keyboard coverage was partial, and an existing blank-quantity behavior removed a cart item. These limitations were recorded; the exercise is not a certification of the whole buyer experience. No APEX reimport was needed, and app 101 was preserved.
