The snippet fixes the trace, but the customer would still get the same answer. After the except block, fallback_value goes back to the model as if the tool had returned it, so the span says ERROR while the summary still says the refund went through.
For a payment timeout I'd return neither a default nor a stack trace, but an explicit unknown, something like {"status": "unknown", "refund_id": null}, that the summary step isn't allowed to report as done. Then check with the provider before anything reaches the customer. On Stripe that's listing refunds filtered by the charge, and sending an Idempotency-Key with the refund request makes the harness's own retries safe in the first place.
The snippet fixes the trace, but the customer would still get the same answer. After the except block, fallback_value goes back to the model as if the tool had returned it, so the span says ERROR while the summary still says the refund went through.
For a payment timeout I'd return neither a default nor a stack trace, but an explicit unknown, something like {"status": "unknown", "refund_id": null}, that the summary step isn't allowed to report as done. Then check with the provider before anything reaches the customer. On Stripe that's listing refunds filtered by the charge, and sending an Idempotency-Key with the refund request makes the harness's own retries safe in the first place.