View Issue Details

IDProjectCategoryView StatusLast Update
0006445Talermerchant backend API (C)public2020-09-05 13:27
ReporterChristian Grothoff Assigned ToChristian Grothoff  
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionreopened 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product Versiongit (master) 
Target Version0.8Fixed in Version0.8 
Summary0006445: POST /private/orders is not idempotent
DescriptionIf 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.
TagsNo tags attached.

Activities

jonathanbuchanan

2020-08-02 04:01

developer   ~0016540

implemented in 859675f..b90d7d2.

Christian Grothoff

2020-09-03 23:50

manager   ~0016832

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...

Christian Grothoff

2020-09-05 13:20

manager   ~0016869

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.

Christian Grothoff

2020-09-05 13:27

manager   ~0016870

Deployments updated.

Issue History

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