tulshi
commented
1 year ago I'd like to suggest that if the Receiver wants to send the "events_delivered" claim in a PATCH request to the stream, it should match the value of the "events_delivered" at the time the request is made (i.e. before the request has had any effect). This is because the Receiver will not know what the Transmitter is willing to provide to it in "events_delivered". It may happen that the Transmitter decides to only include a subset of the "events_requested" in the "events_delivered" in its response.
FragLegs
The spec says that if any Transmitter-supplied values are present in the PUT or PATCH calls to the stream management endpoint, they should be checked against the values that the Transmitter believes are true and an error should be raised if the values don't match. We put this in so that Receivers could a) simply GET a stream, update values, and send that object to PUT/PATCH and b) confirm that their expectations from the Transmitter are correct.
However, "events_delivered" is a function of both "events_supported" (Transmitter-supplied) and "events_requested" (Receiver-supplied). It is unreasonable to ask the Receiver to guess what the "events_delivered" value will be, and it will change based on the "events_requested" that get sent up.
How should the Transmitter respond if the "events_delivered" value in the PUT/PATCH request does not match the "events_delivered" value that the Transmitter knows? Should those values be compared before or after applying the changes to "events_requested"?