Handle Idempotency-Key in requisition create/status change endpoints

Description

All requisition create/status changes endpoints (initiate, submit, authorize, reject.. etc.) should handle an optional Idempotency-Key request header. If the Idempotency-Key is provided, the backend must validate that the request with the same key has not been used yet (in order to avoid creating or updating the resource twice). If the request with the given key has already been received we should return 409 Conflict HTTP status code with a meaningful error message. Additionally, if that request has already been completed successfully (meaning the resource was created/updated) the Location header in the response should be set to point to the created/updated resource. An Idempotency-Key should be a v4 UUID. Once used Idempotency-Key should not be available for the next 24 hours (meaning it should return 409 as specified above).

Acceptance criteria:

  • Create/Status changes endpoints (such as initiate, submit, authorize, reject, etc.) should all support optional "Idempotency-Key" request header

  • The Idempotency-Key request header is optional and the requests continue to work if it's not provided with the request

  • The Idempotency-Key is a v4 UUID

  • If the Idempotency-Key has already been used a 409 Conflict status code is returned with a meaningful error message

  • If the Idempotency-Key has already been used and the request has succeeded the Location response header is set to point to the created/updated resource

  • The same Idempotency-Key can only be re-used after 24 hours

  • An idempotency key is checked after authorization checks have passed (that is, if I don't have rights for the resource, I'm getting 403, no matter if the idempotency key has been used or not)

Implementation notes

  • Consider using Redis in-memory database to manage idempotency keys (this is not a requirement)

Activity

Show:
Mateusz Kwiatkowski
July 17, 2018, 8:48 AM

I think that those issues are definitely not connected to this ticket, most likely there were linked because wanted to create or reset password during testing of this ticket, but those are connected to work in progress on User Details and Notification service of Mind the Gap team. I'm not sure if those issues are still relevant or they were fixed already.

Sam Im
July 17, 2018, 1:52 AM

Are the bugs that are linked to this ticket correctly linked? If so, then if I retest those bug scenarios should they be resolved?

Joanna Szymańska
July 5, 2018, 10:09 AM

I checked again and still in both instances the same request (batchReleases) is made, but now it contain the Idempotency Key, so I think everything works well for the moment.

Joanna Bebak
July 4, 2018, 6:15 AM
Edited

I resumed testing the ticket and see that converting requisitions to orders and releasing them without converting them to orders works correctly but in both instances the same request is made - batchReleases - is made, and it doesn't contain the Idempotency Key header. Now, I'll check what happens when a request is not successful.

EDIT: I finished testing the ticket, and apart from the above-mentioned issue, everything works correctly.

Joanna Bebak
July 3, 2018, 12:46 PM

OK, I see. I'll re-test the issues that I found in accordance with your suggestions and let you know in case I have any doubts.

Done

Assignee

Mateusz Kwiatkowski

Reporter

Sebastian Brudziński