| Confirmed _not_ working. | |
| For now, problem seems to be 1h future_retry timeout in taler-merchant-depositcheck which is triggered because when we look at _exactly_ the wire deadline, the exchange is not yet done, and so then we wait 1h. Probably should introduce some general slack before checking for wire transfers (1s?), and/or use some exponential back-off. | |
| Additional issue: depositcheck's pg_insert_deposit_to_transfer.sql first checks if the wire transfer actually is confirmed (SELECT ... FROM merchant_transfers CROSS JOIN...). Two problems: here it is assumed that the exchange_pub is the *same* for both messages (doesn't have to be!), and if the merchant_transfer doesn't exist, we simply do nothing (qs = 0). That might be fine (no wire transfer yet!), but we then do not update anything about the pending deposit status, so *immediately* retry the same deposit again, again querying the exchange, in a busy loop that just does DB-exchange-DB interactions and never terminates and never moves on to the next transaction. So very fatal. The loop _might_ be broken if the wire transfer is actually added, that still needs to be tested. | |
| Trying to manually add the wire transfer failed (see screenshot, with error message in bad english). bad-english.png (85,915 bytes) | |
| Oddly enough, repeating the same POST (trying to see the exact response), succeeded. Logs for the first transfer show: 2024-01-26T01:08:56.828203+0100 pq-1149038(6QE6W1FG1X5H77XT8MHBDK3BF0) INFO Query `insert_transfer' failed with result: could not serialize access due to concurrent update/(null)/ERROR: could not ser ialize access due to concurrent update /PGRES_FATAL_ERROR/ERROR: could not serialize access due to concurrent update 2024-01-26T01:08:56.828907+0100 pq-1149038(6QE6W1FG1X5H77XT8MHBDK3BF0) ERROR Query `set_transfer_sta tus_to_confirmed' failed with result: current transaction is aborted, commands ignored until end of transaction block/(null)/ERROR: current transaction is aborted, commands ignored until end of trans action block /PGRES_FATAL_ERROR/ERROR: current transaction is aborted, commands ignored until end of transaction block 2024-01-26T01:08:56.828936+0100 taler-merchant-httpd-1149038(6QE6W1FG1X5H77XT8MHBDK3BF0) ERROR Assertion failed at taler-merchant-httpd_private-post-transfers.c:104. | |
| After that, the 'wire_pending' flag does go to 'false' in the merchant_deposit_confirmations table. However, the 'wired' bit in merchant_contract_terms remains on 'false'. We probably lack the logic to set the contract_terms 'wired' flag when all deposit confirmations associated with a contract have gone to not wire_pending. | |
| Exponential retry-backoff implemented in 0b85857..52f2abe. | |
| Ok, I'm concluding that as-is, this is not directly implementable as the *schema* requires a certain sequence of events from the taler-merchant-(wirewatch, depositcheck, exchange) helpers which is not guaranteed to happen --- taler-merchant-(wirewatch, exchange, depositcheck) could happen just as easily, or taler-merchant-(depositcheck, wirewatch, exchange) and all but one of the 3 plausible orders will fail to clear the 'wired' flag and/or have other problems. The primary culprit is the 'credit_serial' FK in the deposit_to_transfer table. Replacing that with a non-FK wtid should allow any sequence to happen *and* to be implemented in a way to clear the 'wired' flag at the end. | |
| e3c4f55..159591d implements the schema changes. Still needs more testing to be confident about the fix. | |
| Shell script testing the various scenarios now exists, and passes. "real-world" test still pending. | |
| Finally finished. So many sub-problems, incredible. :-( | |
- Anonymous