Transaction saying its failing but actually goes through

[linear]

Overview

ShapeShift claims there is an error after submitting a tx, then when I submit the tx again, I see that the first one worked too, so I end up with 2 pretty much similar transactions.
Usually it's Portals that gives me the error though. It spits the Failed to execute 'json' on 'Response': body stream already read, but the tx goes through successfully

References and details

https://jam.dev/c/bba94301-5b6e-4098-8196-1d4549bcde9f

1. here is a jam of it happening (from about 00:40ish)

Acceptance Criteria

The criteria that means the fix is complete. Avoid "it fixes the problem." Include an ideal flow and consult the DAO for input here after making the issue.

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and agent prompts for this issue.

• Create Plan

Examples

• Example 1
• Example 2

🔗 Related PRs

#10730 - fix: better handle send errors in send flow [merged]
#10985 - fix: portals bad boy delta [merged]
#11283 - fix: implement proper TRON getTransaction and fix Sun.io status checking [merged]
#11348 - fix: prevent Sun.io false transaction failures on Tron [merged]

👤 Suggested Assignees

• gomesalexandre
• premiumjibles

---

🧪 Issue enrichment is currently in early access.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

[0xApotheosis]

From a parse of the attached Jam, we see 2 send requests occurring (OPTIONS and a POST), and the second send returns a 500, at which time we throw the error message to the user. By the look of the timing, it's hitting a 5 second timeout, and returning 500, but I suspect it's actually still going through on the backend when we do so.

It's possible this is or was an ephemeral issue related to node health. However, we still want to handle the case where we take more than five seconds to submit the transaction. Because it seems like even when the backend returns 500, we still may process the TX eventually.

A quick fix might be to simply kill the request in the backend at the time that we send the 500 to the front end. Or we could up the timeout to say 10 seconds.