Abstract
Change repeaters to not retry HTTP 409 responses
Motivation
OpenFN+OpenHIM users wanted a way to differentiate between traffic that was sent and traffic they didn't forward due to internal preconditions. It's at least somewhat common for systems to respond to duplicates with an HTTP 409, meaning "I already have a record for this, and don't want a new one." We are also likely to implement a "What you are sending is already on the server, and I don't need it" 409 response on CloudWorks for different reasons, so it's well aligned for consistency.
Specification
When HQ receives a 409 response to a Form Forwarding POST, it should not try to resend the record. Whether it is treated as a success or a failure internally is an open question. I
Impact on users
No impact on front-end users. Allows backend / API users slightly more granularity in interacting with CommCare.
Impact on hosting
Introduces more complexity in the array of potential interactions HQ can have in the API layer, including encouraging a new
Backwards compatibility
It should be evaluated whether we are currently receiving 409 responses from real servers. Clayton can evaluate that.
Abstract
Change repeaters to not retry HTTP 409 responses
Motivation
OpenFN+OpenHIM users wanted a way to differentiate between traffic that was sent and traffic they didn't forward due to internal preconditions. It's at least somewhat common for systems to respond to duplicates with an HTTP 409, meaning "I already have a record for this, and don't want a new one." We are also likely to implement a "What you are sending is already on the server, and I don't need it" 409 response on CloudWorks for different reasons, so it's well aligned for consistency.
Specification
When HQ receives a 409 response to a Form Forwarding POST, it should not try to resend the record. Whether it is treated as a success or a failure internally is an open question. I
Impact on users
No impact on front-end users. Allows backend / API users slightly more granularity in interacting with CommCare.
Impact on hosting
Introduces more complexity in the array of potential interactions HQ can have in the API layer, including encouraging a new
Backwards compatibility
It should be evaluated whether we are currently receiving 409 responses from real servers. Clayton can evaluate that.