View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005503 | Taler | merchant backend | public | 2018-12-22 11:47 | 2019-12-20 18:12 |
| Reporter | Christian Grothoff | Assigned To | Christian Grothoff | Resolution deadline | |
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | urgent | Severity | block | Reproducibility | random |
| Status | closed | Resolution | fixed | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 0.6 | Fixed in Version | 0.6 | ||
| Summary | 0005503: {'code': 2501, 'hint': 'db error: could not check for existing order'} | ||||
| Description | A user reports: This message appeared while paying for a chapter of Stallmans book: {'code': 2501, 'hint': 'db error: could not check for existing order'} | ||||
| Additional Information | The 2501 error had 5 (!) different meanings, I've changed the code now to disambiguate them. That said, the "hint" narrows it down to just two cases, either a hard or a soft transaction failure when we ask the DB about the existing contract. I'm not sure why the 'soft' error isn't retried, but it seems unlikely that we had a truly conflicting transaction given our current transaction rate and that Peter tried several times. My best guess right now is that we're missing a commit/rollback somewhere and thus everything is run as part of some 'ancient' transaction (and thus if we re-start the merchant, things will start to work again just until we get into that logic of the not properly terminated transaction). Analysis shows that the _proposal.c logic of the merchant backend doesn't seem to properly deal with transactions (I see no begin/commit, but multiple SQL statements!), and also while there is a MAX_RETRIES the SOFT case is not retried. This may not explain this bug, but there is work to be done there!!! | ||||
| Tags | No tags attached. | ||||
| Marcello is right (in his e-mail) that there is nothing more to be done here, in part because I actually did go over the file in the meantime, just forgot to 'resolve' this bug. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-12-22 11:47 | Christian Grothoff | New Issue | |
| 2018-12-22 11:47 | Christian Grothoff | Status | new => assigned |
| 2018-12-22 11:47 | Christian Grothoff | Assigned To | => Marcello Stanisci |
| 2019-01-31 17:51 | Christian Grothoff | Assigned To | Marcello Stanisci => Christian Grothoff |
| 2019-01-31 17:51 | Christian Grothoff | Status | assigned => informing |
| 2019-01-31 17:51 | Christian Grothoff | Resolution | open => fixed |
| 2019-01-31 17:51 | Christian Grothoff | Fixed in Version | => 0.6 |
| 2019-01-31 17:51 | Christian Grothoff | Note Added: 0013539 | |
| 2019-12-20 18:12 | Christian Grothoff | Status | informing => closed |
| 2025-03-22 13:09 | Christian Grothoff | Category | mechant backend => merchant backend |