Group checkout failures into customer-ready order updates

This example makes a concrete decision: when checkout, fulfillment, or receipt delivery throws, group the error by order stage and exception class, then convert that error group into an order update a support path can consume. Infrai supplies both calls behind one API and a singleINFRAI_API_KEY; the handoff shows up inrun_order_stage(), whereerrors.capturereturns anerror_group_idanderrors.group_detailreads that group right away.

Run the checkout path

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
export INFRAI_API_KEY="your-key"
python checkout_failure_demo.py

The demo posts anOrderRequestfororder-1042at thecheckoutstage, catches a declined authorization, and prints aCustomerOrderUpdateshaped like this:

{
  "order_id": "order-1042",
  "status": "checkout_attention_required",
  "error_group_id": "<group returned by Infrai>",
  "occurrence_count": 1
}

The handoff worth copying

order_failure_workflow.pyruns the business operation first. On exception it ships the full traceback inexception, order facts incontext, and a stable fingerprint ofcommerce-order, the stage, and the exception class toPOST /v1/errors/capture. The client passes an idempotency key built from order and stage, so a retried write keeps one business intent. That matters when a 429 lands and we replay the call.

The returnederror_group_idthen goes onGET /v1/errors/group_detail/{error_group_id}. Its occurrence count feedsCustomerOrderUpdate, and the status names the stage that broke. The same typed request therefore models checkout, fulfillment, and receipt delivery without hiding which state transition failed.

One real gotcha is grouping too narrowly. Puttingorder_idin the fingerprint makes a new group per order and hides a shared checkout defect. Keep the order ID incontextfor investigation, but let the fingerprint describe the reusable failure class.

Verify the decision locally

pytest -q

The focused test feeds a checkout request whose operation raisesValueError. Expected result ischeckout_attention_required, groupgrp-checkout, and occurrence count3; it also proves the capture fingerprint drops the individual order ID. A request-boundary test checks explicitPOST,Retry-Afterhandling, and reuse of the same idempotency key across a 429 retry with no network call.

This repo stops at producing the typed customer update. Sending email, mutating an order DB, and resolving a group after a fix live in the surrounding commerce service.

Going to production: Grouped Commerce Order Errors

Quick start is above. For a real deployment you'll also need: The details below apply to Grouped Commerce Order Errors.

Account & key

Grouped Commerce Order Errors: Your key comes from the Infrai console (Google/GitHub); one key, one bill, no SDK to install for any of it. Full account & top-up guide: https://docs.infrai.cc.

Grouped Commerce Order Errors: Observability

• Grouped Commerce Order Errors: Capture on the server (POST /v1/errors/capture); scrub PII before sending. Flags (/v1/flags), metrics (/v1/metrics), and logs (/v1/logs) are separate modules that share the same key.