Failed to fetch deposits: 500 and Reveal not saved properly in the database, response: 500 after requesting deposit

[michalinacienciala]

I encountered a strange behavior when trying to do a deposit from a Native address via LL on Mainnet. I entered the amount on the deposit form, pressed Deposit and got stuck with the spinning wheel on the form, no transaction was shown for signing. In the logs there were some errors related to reading and writing from/to D1. I suspect this issue is not related to LL and is more about the Cloudflare DB responsiveness...

Screen.Recording.2024-11-18.at.09.22.05.mov

The Failed to fetch deposits: 500 is something that we saw before in the past in the production Sentry logs, but were not sure of the cause. Both now and in the past the accounts which experienced the error did not have any deposits yet.

As for the Reveal not saved properly in the database, response: 500, the error suggest the reveal data was not saved, but on the db I see it was:

I see that the Failed to fetch deposits: 500 is listed in the prop-dapp-standalone Sentry errors.

As for Reveal not saved properly in the database, response: 500 I don't see it anywhere in Sentry. If the reveal indeed wasn't saved (which wasn't a case for me, but may be an issue in some other error occurrences), it would be good to have an error about it in Sentry and have the reveal data listed in the error, to be able to add that data manually (this is how it works in Mezo). Having the reveal data saved is crucial for funds processing/recovery in unlucky cases where the deposits data isn't saved correctly.

---

When I closed the pending deposit form and opened it again to try one more time, this time the deposit went smooth.

---

Let's see if we can get rid of the root cause of the issue, and if not, let's at least ensure we're capturing the reveal info in Sentry error.

[linear]

AENG-26 `Failed to fetch deposits: 500` and `Reveal not saved properly in the database, response: 500` after requesting deposit

[michalinacienciala]

We have another occurrence of the Reveal not saved properly in the database issue and Failed to fetch deposits: 500, in Sentry.
Both issues have the exact same timestamp, but show different browser, release and user info.
This different release value (fff5028484ad vs 1d3275110e1c) is particularly interesting to me. Our main code was on fff5028484ad until Nov 26, 8:57 UTC, where we merged #769 and when the latest commit sha changed to 1d3275110e1c (and the standalone production got updated to the latest commit). The errors in Sentry are from Nov 26, 9:31 UTC. Maybe the Sentry error that occurred on fff5028484ad was from user who opened the browser before 8:57 and then the user tried to do something at 9:31 and the error has occurred, still noting the fff5028484ad as release in Sentry (I'm not sure if the error is caused by the fact that user was on an older code of the dapp, whereas our backend was already on a newer commit, or if that's completely unrelated).

Anyway, if we observe the issues again, we can look if there are any similarities/patterns in the behavior.