Skip to main content
A checkout completes successfully but charges a loyalty customer 3564 cents. The expected total is 3208 cents. This walkthrough follows the actual recording to the calculation that produced the difference, then verifies a source correction. The example has two order lines: two notebooks at 1200 cents each and three pens at 300 cents each. Its business rule applies a 10% loyalty discount, then 8% tax on the discounted subtotal, rounded to the nearest cent. Customer, catalog, inventory and payment responses are fixed local data; no payment is sent or inventory changed. The recording has fourteen call nodes and fifteen attempts. The two payment invocations are recorded as attempts of one call. It includes a recovered payment error, but the failed call is not the cause of the incorrect total. Use fully qualified names in queries, such as __main__.discount_for. The example records values with capture enabled and value_sample_rate=1.0. Available values in your deployment depend on capture controls and retention. Follow the same investigation with an identifier from your own service. To reproduce this specific case, run the supplied local example first; it is separate from Quickstart’s order check and from the correctly priced graph in The execution graph.

​
Record the example (optional)

Use the installed SDK and running server/relay from Quickstart. Set the queue directory in this terminal, replacing the path with the relay’s absolute path:
The application and relay must access that same directory. Open the example sources and save checkout_service.before.py and checkout_service.after.py in the directory containing .venv. Run the original pricing implementation with its source fingerprint attached to the recording:
Keep APP_REVISION when selecting this recording. After the correction below, run the corrected source to produce a second revision of the same order.

​
Find the request

With read access to an instance containing the execution, enter its order identifier in the UI’s home search. For this example, enter order-1042 and submit Search. On the results page, narrow Service to checkout-investigation. Distinguish the original and corrected runs by their timestamp and app_revision tag. See Search traces for scope and time controls. Open the matching trace. Check the service, identifier, timestamp and application revision before relating it to source code. In this capture, app_revision is a declared trace tag containing a SHA-256 fingerprint of the application file. The entry point accepts that value as an argument, declared through tag_keys=["order_id", "app_revision"]; see searchable identifiers. The root status is ok and recording completeness is complete. The order handler returned normally; neither field establishes that it calculated the intended price.

​
Follow the calculation

Start with the graph. checkout calls price_order, which calls price_lines, discount_for and tax_for. The line-pricing branch descends through two line_total calls, each with a unit_price lookup. The later payment call consumes the price already calculated. In the UI, select price_order, open Output and choose fetch full value. This read returned:
The subtotal is consistent with the order: 2400 cents for notebooks and 900 for pens. The unexpected field is discount_cents: 0. Inspect that calculation before attributing the total to the payment retry.

​
Inspect the successful call

Select discount_for. Its attempt status is ok. Read Input and Output. Selected input and output from discount_for:
The actual input contains loyalty_member: true; the function still returned zero. The recording establishes that the flag reached this call. It also shows tax_for receiving 3300 cents and returning 264, which explains the final total of 3564. This narrows the source inspection to the discount calculation. Successful completion is compatible with an incorrect result, so restricting the investigation to error nodes would miss the relevant call.

​
Match the recording to source

At the captured application revision, the discount helper was:
It checks is_member, while the actual customer has loyalty_member. The absent key falls back to false, producing the recorded zero discount. The mismatch is in the calculation; the customer lookup supplied the expected membership field. Use the source revision associated with the recording. A file and line number from a captured stack does not identify a deployment revision, and the SDK version is a different field.

​
Verify the correction

The correction uses the field supplied by the customer record:
With discount_for defined by the helper excerpt above, the regression assertion was:
With the downloaded example, test the original implementation directly:
The assertion fails against the original implementation. Replace it with the supplied corrected source and record the same order at its new revision:
Run the assertion again; it passes. Find the new recording using its app_revision tag. The before and after recordings show: The new graph shows a 330-cent discount, tax calculated on 2970 cents, and a 3208-cent total. Both entry points completed normally. The differing values explain what changed; the status badge alone would not. This verifies the example’s input case and source correction. In your service, test the required customer schemas and other callers as well. Observed callers and one regression case cannot establish that every possible input remains compatible.

​
Use the recording with an agent

An agent can follow the same evidence: find the order, read the graph, then retrieve the customer and discount values. Give it the expected pricing rule and the matching source revision so it can relate the recorded behavior to the implementation. In an MCP session for this example, the agent read those values and the source helper shown above. Its diagnosis began:
The discount helper checks the wrong key, so it never applies the discount.
Use the corrected helper and regression test above to verify that conclusion. To repeat the reads with your agent, connect an MCP client and follow Use execution data. The latter explains how to select runtime evidence for a task and manage the returned data in the agent’s context.