View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007104 | Taler | merchant backend | public | 2021-11-23 11:27 | 2022-11-04 19:52 |
| Reporter | Florian Dold | 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 | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.9 | Fixed in Version | 0.9 | ||
| Summary | 0007104: merchant logs a 500 response from the exchange even though a merchant DB error occurred | ||||
| Description | in ..._post-orders-ID-pay.c, we call resume_pay_with_error (pc, MHD_HTTP_INTERNAL_SERVER_ERROR, TALER_EC_GENERIC_DB_STORE_FAILED, "deposit"); when we get a hard error from our database. This subsequently causes a log message that makes it *look* like there was an error with the exchange interaction, even when that is not the case. | ||||
| Tags | No tags attached. | ||||
| I don't see why you say that. 500 is clearly an internal error, and the EC also points to OUR database. 502/504 are used for exchange errors. The logging is also pretty clear. I'm changing the hint to "insert_deposit" as that is the database interaction. But I don't see what else to do here. | |
| 2df6e15..17f156a | |
| In resume_pay, we log the following message: GNUNET_log (GNUNET_ERROR_TYPE_DEBUG, "Resuming /pay handling as exchange interaction is done (%u)\n", response_code); Thus when the merchant experiences an internal database problem, we log that we got a 500 in an interaction with the exchange. *That's* the confusing part. | |
| Well. Read the message: the exchange interaction is done. *OUR* HTTP request status is 500. response_code is always what WE return, not what we got from the exchange. Anyway, I've clarified the log statement in e3e693d..3b9e74b | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2021-11-23 11:27 | Florian Dold | New Issue | |
| 2021-11-23 11:27 | Florian Dold | Status | new => assigned |
| 2021-11-23 11:27 | Florian Dold | Assigned To | => Christian Grothoff |
| 2021-11-25 22:13 | Christian Grothoff | Note Added: 0018546 | |
| 2021-11-25 22:13 | Christian Grothoff | Status | assigned => informing |
| 2021-11-25 22:13 | Christian Grothoff | Resolution | open => fixed |
| 2021-11-25 22:13 | Christian Grothoff | Fixed in Version | => 0.9 |
| 2021-11-25 22:13 | Christian Grothoff | Note Added: 0018547 | |
| 2021-11-25 22:25 | Florian Dold | Note Added: 0018549 | |
| 2021-11-25 22:25 | Florian Dold | Status | informing => feedback |
| 2021-11-25 22:25 | Florian Dold | Resolution | fixed => reopened |
| 2021-11-25 22:43 | Christian Grothoff | Note Added: 0018552 | |
| 2021-11-25 22:43 | Christian Grothoff | Status | feedback => informing |
| 2021-11-25 22:43 | Christian Grothoff | Resolution | reopened => fixed |
| 2022-10-20 08:48 | Christian Grothoff | Target Version | => 0.9 |
| 2022-11-04 19:52 | Christian Grothoff | Status | informing => closed |
| 2025-03-22 13:09 | Christian Grothoff | Category | mechant backend => merchant backend |