---
title: "Comment by Mike Dabydeen on \"My agent said the refund went through. The ticket went to the one team that could not fix it.\" | Hashnode"
description: "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"
url: "https://hashnode.com/posts/my-agent-said-the-refund-went-through-the-ticket-went-to-the-one-team-that-could-not-fix-it/6ace594f30baba0d7409c897/comment/6acf64e4472088dacd51b198"
---

[Discussion](https://hashnode.com/posts/my-agent-said-the-refund-went-through-the-ticket-went-to-the-one-team-that-could-not-fix-it/6ace594f30baba0d7409c897)

Comment [My agent said the refund went through. The ticket went to the one team that could not fix it.](https://hashnode.com/posts/my-agent-said-the-refund-went-through-the-ticket-went-to-the-one-team-that-could-not-fix-it/6ace594f30baba0d7409c897)

[Mike Dabydeen](https://hashnode.com/@firelinks)

[Oct 14](https://hashnode.com/posts/my-agent-said-the-refund-went-through-the-ticket-went-to-the-one-team-that-could-not-fix-it/6ace594f30baba0d7409c897/comment/6acf64e4472088dacd51b198)

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.