View Issue Details

IDProjectCategoryView StatusLast Update
0008061Talermechant backendpublic2024-03-07 20:47
ReporterChristian Grothoff Assigned ToChristian Grothoff  
Status closedResolutionfixed 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product Versiongit (master) 
Target Version0.9.4Fixed in Version0.9.4 
Summary0008061: taler-merchant-exchange fails to set 'wired' flags on the order
DescriptionOne bug was fixed in the SQL, still needs to be verified that it is working now.
TagsNo tags attached.


parent of 0008168 closedAntoine A fails to set IBAN for exchange 
child of 0008153 closedChristian Grothoff test, package and upload merchant 0.9.4 to ftp and stable Debian/Ubuntu server 


Christian Grothoff

2024-01-25 23:56

manager   ~0021039

Confirmed _not_ working.

Christian Grothoff

2024-01-26 00:19

manager   ~0021042

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.

Christian Grothoff

2024-01-26 01:08

manager   ~0021043

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.

Christian Grothoff

2024-01-26 01:10

manager   ~0021044

Trying to manually add the wire transfer failed (see screenshot, with error message in bad english).
bad-english.png (85,915 bytes)   
bad-english.png (85,915 bytes)   

Christian Grothoff

2024-01-26 01:11

manager   ~0021045

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

2024-01-26T01:08:56.828936+0100 taler-merchant-httpd-1149038(6QE6W1FG1X5H77XT8MHBDK3BF0) ERROR Assertion failed at taler-merchant-httpd_private-post-transfers.c:104.

Christian Grothoff

2024-01-26 01:15

manager   ~0021046

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.

Christian Grothoff

2024-01-26 18:25

manager   ~0021051

Exponential retry-backoff implemented in 0b85857..52f2abe.

Christian Grothoff

2024-01-26 19:54

manager   ~0021052

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.

Christian Grothoff

2024-01-26 22:40

manager   ~0021053

e3c4f55..159591d implements the schema changes. Still needs more testing to be confident about the fix.

Christian Grothoff

2024-01-28 15:04

manager   ~0021061

Shell script testing the various scenarios now exists, and passes. "real-world" test still pending.

Christian Grothoff

2024-01-29 00:02

manager   ~0021065

Finally finished. So many sub-problems, incredible. :-(

Issue History

Date Modified Username Field Change
2024-01-10 16:57 Christian Grothoff New Issue
2024-01-10 16:57 Christian Grothoff Status new => assigned
2024-01-10 16:57 Christian Grothoff Assigned To => Christian Grothoff
2024-01-17 19:42 Christian Grothoff Category exchange => mechant backend
2024-01-20 18:28 Christian Grothoff Relationship added related to 0008153
2024-01-20 18:28 Christian Grothoff Relationship deleted related to 0008153
2024-01-20 18:28 Christian Grothoff Relationship added child of 0008153
2024-01-21 16:56 Christian Grothoff Relationship added parent of 0008168
2024-01-25 23:56 Christian Grothoff Note Added: 0021039
2024-01-26 00:19 Christian Grothoff Note Added: 0021042
2024-01-26 01:08 Christian Grothoff Note Added: 0021043
2024-01-26 01:10 Christian Grothoff Note Added: 0021044
2024-01-26 01:10 Christian Grothoff File Added: bad-english.png
2024-01-26 01:11 Christian Grothoff Note Added: 0021045
2024-01-26 01:15 Christian Grothoff Note Added: 0021046
2024-01-26 01:15 Christian Grothoff Severity major => block
2024-01-26 18:25 Christian Grothoff Note Added: 0021051
2024-01-26 19:54 Christian Grothoff Note Added: 0021052
2024-01-26 22:40 Christian Grothoff Note Added: 0021053
2024-01-28 15:04 Christian Grothoff Note Added: 0021061
2024-01-29 00:02 Christian Grothoff Status assigned => resolved
2024-01-29 00:02 Christian Grothoff Resolution open => fixed
2024-01-29 00:02 Christian Grothoff Fixed in Version => 0.9.4
2024-01-29 00:02 Christian Grothoff Note Added: 0021065
2024-03-07 20:47 Christian Grothoff Status resolved => closed