View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005054 | Taler | mechant backend | public | 2017-06-02 13:58 | 2017-10-18 15:42 |
| Reporter | Marcello Stanisci | Assigned To | Marcello Stanisci | ||
| Priority | normal | Severity | minor | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.2 | ||||
| Target Version | 0.4 | Fixed in Version | 0.4 | ||
| Summary | 0005054: 'contract_terms not found' for transaction which correctly went through | ||||
| Description | Sometimes, when the backoffice wants to track an order id, the merchant backend returns 404 indicating that the order id is unknown. This is incorrect, because the order id we want to track is returned by the merchant backend's /history API. As of commit fc6ee7d, the merchant produces more debugging information when the db is involved. Those are logs indicating this situation: Jun 01 16:50:52-716445 taler-merchant-httpd-24124 DEBUG Trying to track h_contract_terms 'CPJB0H5C' Jun 01 16:50:52-716466 taler-merchant-httpd-24124 DEBUG Finding transaction for h_contract_terms 'CPJB0H5C' Jun 01 16:50:52-716476 pq-24124 DEBUG Executing prepared SQL statement `find_transaction' Jun 01 16:50:52-716743 taler-merchant-httpd-24124 DEBUG Could NOT find transaction for h_contract_terms 'CPJB0H5C' Jun 01 16:50:52-716777 taler-merchant-httpd-24124 WARNING h_contract_terms not found | ||||
| Tags | No tags attached. | ||||
| related to | 0005109 | closed | Marcello Stanisci | Need same merchant key regardless of the color |
|
|
I wasn't able to reproduce this locally |
|
|
The bug exists when a payment didn't go through but its proposal has been generated and stored. The /history API - which is the one that populates the backoffice order list - returns all known *contracts*, without making sure that they got payed. So a "flag" that indicates whether a contract has been paid or not is needed to fix this. |
|
|
flagging implemented @ c391606 |
|
|
fixed (?) @ 73e2e5a73. Shortly leaving in feedback status. |
|
|
responded well to manual tests for 2-3 days |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-06-02 13:58 | Marcello Stanisci | New Issue | |
| 2017-06-02 13:58 | Marcello Stanisci | Status | new => assigned |
| 2017-06-02 13:58 | Marcello Stanisci | Assigned To | => Marcello Stanisci |
| 2017-07-14 12:22 | Marcello Stanisci | Status | assigned => feedback |
| 2017-07-14 12:22 | Marcello Stanisci | Note Added: 0012333 | |
| 2017-07-15 15:07 | Marcello Stanisci | Status | feedback => acknowledged |
| 2017-07-15 15:07 | Marcello Stanisci | Note Added: 0012337 | |
| 2017-07-15 15:20 | Christian Grothoff | Status | acknowledged => assigned |
| 2017-07-16 11:56 | Marcello Stanisci | Note Added: 0012338 | |
| 2017-07-16 12:49 | Marcello Stanisci | Status | assigned => feedback |
| 2017-07-16 12:49 | Marcello Stanisci | Note Added: 0012339 | |
| 2017-07-19 09:35 | Marcello Stanisci | Relationship added | related to 0005109 |
| 2017-07-19 11:44 | Marcello Stanisci | Status | feedback => resolved |
| 2017-07-19 11:44 | Marcello Stanisci | Resolution | open => fixed |
| 2017-07-19 11:44 | Marcello Stanisci | Note Added: 0012350 | |
| 2017-07-19 11:45 | Marcello Stanisci | Note Edited: 0012350 | |
| 2017-07-20 09:23 | Christian Grothoff | Fixed in Version | => 0.4 |
| 2017-07-20 09:23 | Christian Grothoff | Target Version | => 0.4 |
| 2017-07-20 09:23 | Christian Grothoff | Description Updated | |
| 2017-10-18 15:42 | Christian Grothoff | Status | resolved => closed |
