View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006445 | Taler | mechant backend | public | 2020-07-25 21:17 | 2024-01-12 14:04 |
| Reporter | Christian Grothoff | Assigned To | Christian Grothoff | ||
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Platform | i7 | OS | Debian GNU/Linux | OS Version | squeeze |
| Product Version | git (master) | ||||
| Target Version | 0.8 | Fixed in Version | 0.8 | ||
| Summary | 0006445: POST /private/orders is not idempotent | ||||
| Description | If a client posts _exactly_ the same request to /private/orders *with* an order_id specified (!), we currently generate an error. Instead, we should create exactly the same response a 2nd time. (Note that this ONLY applies if the client includes the order_id; if there is no order_id, we create one at random so the 2nd response would be different.) Fixing this requires additional logic to check that the request has an order_id and that we have exactly the same order (with the same terms) in the database. This is a bit tricky, as we modify/patch the order (adding merchant details, etc.), so really we can only do the idempotentcy check _after_ patching the incoming order. | ||||
| Tags | No tags attached. | ||||
|
|
implemented in 859675f..b90d7d2. |
|
|
Actually, the fix doesn't work, I just encountered this with my WooCommerce tests. You do: if (1 == json_equal (order, contract_terms)) which likely fails because the stored contract_terms have been modified by the backend, and either (didn't check): - the 'order' has not yet been modified - the modifications are not exactly the same, say because we are adding some relative time as an offset and then the result ends up _slightly_ different. So yeah, getting this right will be a bit funky. :-( I propose we only compare a few fields: - products - summary / summary_i18n - fulfillment_url - locations - total price - order_id (doh) - auto_refund - extra and leave out the timestamps. Hopefully that'll work... |
|
|
c0f9922..6f8c224 implements a more principled approach by storing the hash of the original POST request into the DB and we check against that for idempotency. |
|
|
Deployments updated. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-07-25 21:17 | Christian Grothoff | New Issue | |
| 2020-07-25 21:17 | Christian Grothoff | Status | new => assigned |
| 2020-07-25 21:17 | Christian Grothoff | Assigned To | => jonathanbuchanan |
| 2020-08-02 04:01 | jonathanbuchanan | Status | assigned => resolved |
| 2020-08-02 04:01 | jonathanbuchanan | Resolution | open => fixed |
| 2020-08-02 04:01 | jonathanbuchanan | Note Added: 0016540 | |
| 2020-08-07 01:44 | Christian Grothoff | Fixed in Version | => 0.8 |
| 2020-09-03 23:46 | Christian Grothoff | Assigned To | jonathanbuchanan => Christian Grothoff |
| 2020-09-03 23:46 | Christian Grothoff | Assigned To | Christian Grothoff => jonathanbuchanan |
| 2020-09-03 23:50 | Christian Grothoff | Status | resolved => feedback |
| 2020-09-03 23:50 | Christian Grothoff | Resolution | fixed => reopened |
| 2020-09-03 23:50 | Christian Grothoff | Note Added: 0016832 | |
| 2020-09-05 01:47 | Christian Grothoff | Assigned To | jonathanbuchanan => Christian Grothoff |
| 2020-09-05 01:47 | Christian Grothoff | Priority | normal => high |
| 2020-09-05 01:47 | Christian Grothoff | Status | feedback => assigned |
| 2020-09-05 13:20 | Christian Grothoff | Note Added: 0016869 | |
| 2020-09-05 13:27 | Christian Grothoff | Status | assigned => resolved |
| 2020-09-05 13:27 | Christian Grothoff | Note Added: 0016870 | |
| 2021-08-24 16:23 | Christian Grothoff | Status | resolved => closed |
| 2024-01-12 14:04 | Christian Grothoff | Category | merchant backend API (C) => mechant backend |
