My mistake, this has nothing to do with the DB constraint. The two withdrawals have the same TXID but are to different addresses. This is obviously wrong.
What I think happened is this:
1. You issued two withdrawals. Both became pending.
2. The first withdrawal was attempted by a cron job. For safety, when a withdrawal is attempted, it is first marked as done and then if it fails it is marked as failed.
3. After 1 minute, or due to manual trigger, a second cron job started executing the second withdrawal. The second withdrawal was marked as done and was then attempted.
4. The first withdrawal succeeded and its TXID was marked in the database.
5. The cron job for the second withdrawal timed out. The DB entry remained in a done state.
6. The second withdrawal failed possibly due to lack of funds in the hot wallet.
In short, this is a double-spend due to a race condition. I have not yet understood why the two entries would get the same TXID.
Fortunately the upcoming wallets6 has better prevention to ensure that two cron jobs do not run concurrently. My aim now is to patch such issues with the old codebase for as long as necessary, until the better architectural design of wallets6 is online.
I will now release a patch to the monero coin adapter that prevents this situation from happening again. I think the safest way is to lock withdrawals before each withdrawal and only unlock them after the withdrawal succeeds or fails. The lock can be implemented as a transient, so that in case of a timeout or other crash, the lock will eventually be released after a reasonable amount of time (e.g. 5 minutes).
Thank you for identifying this issue, as double-spends are always very serious issues!
I will post again here when I release the relevant patch. I aim to release a fix to this serious issue, either today or very soon.
with regards