Stream: fhircast-github
Topic: fhircast-docs / issue #381 clarify asynchronous Hub rejec...
Github Notifications (FHIRcast) (Feb 23 2022 at 15:26):
isaacvetter opened issue #381:
The language here: http://fhircast.org/specification/STU2/#request-context-change describes how the hub can asynchronously reject a context change before distributing it to the other applications:
Similar to the Hub's notifications to the subscriber, the subscriber MAY request context changes with an HTTP POST to the hub.url. The Hub SHALL either accept this context change by responding with any successful HTTP status or reject it by responding with any 4xx or 5xx HTTP status. Similar to event notifications, described above, the Hub MAY also respond with a 202 (Accepted) status, process the request, and then later**, instead of broadcasting the context change,** respond with a syncerror event in order to reject the request. **In this specific case in which the context change is rejected by the Hub and not broadcasted,** the syncerror would only be sent to the requestor. The **requestor** SHALL be capable of gracefully handling a rejected context request. Once a requested context change is accepted, the Hub SHALL broadcast the context notification to all subscribers, including the original requestor. The requestor can use the broadcasted notification as confirmation of their request. The Hub reusing the request's id is further confirmation that the event is a result of their request.
Github Notifications (FHIRcast) (Feb 23 2022 at 15:28):
isaacvetter edited issue #381:
The language here: http://fhircast.org/specification/STU2/#request-context-change describes how the hub can asynchronously reject a context change before distributing it to the other applications. This caused confusion/questions during the FHIRcast Hackathon today, because it wasn't clear that this was describing a special case of the Hub rejecting the context change and therefore generating a syncerror, vs the typical use of syncerror, in which the context event is broadcasted and one of the subscribing applications generates a syncerror and it's distributed.
New or changed text in bold. This should be a nonfunctional clarification.
Similar to the Hub's notifications to the subscriber, the subscriber MAY request context changes with an HTTP POST to the hub.url. The Hub SHALL either accept this context change by responding with any successful HTTP status or reject it by responding with any 4xx or 5xx HTTP status. Similar to event notifications, described above, the Hub MAY also respond with a 202 (Accepted) status, process the request, and then later, instead of broadcasting the context change, respond with a syncerror event in order to reject the request. In this specific case in which the context change is rejected by the Hub and not broadcasted, the syncerror would only be sent to the requestor. The requestor SHALL be capable of gracefully handling a rejected context request.
Once a requested context change is accepted, the Hub SHALL broadcast the context notification to all subscribers, including the original requestor. The requestor can use the broadcasted notification as confirmation of their request. The Hub reusing the request's id is further confirmation that the event is a result of their request.
Github Notifications (FHIRcast) (Feb 23 2022 at 15:30):
isaacvetter edited issue #381:
The language here: http://fhircast.org/specification/STU2/#request-context-change describes how the hub can asynchronously reject a context change before distributing it to the other applications. This caused confusion/questions during the FHIRcast Hackathon today, because it wasn't clear that this was describing a special case of the Hub rejecting the context change and therefore generating a syncerror, vs the typical use of syncerror, in which the context event is broadcasted and one of the subscribing applications generates a syncerror and it's distributed.
New or changed text in bold. This should be a nonfunctional clarification.
Similar to the Hub's notifications to the subscriber, the subscriber MAY request context changes with an HTTP POST to the hub.url. The Hub SHALL either accept this context change by responding with any successful HTTP status or reject it by responding with any 4xx or 5xx HTTP status. Similar to event notifications, described above, the Hub MAY also respond with a 202 (Accepted) status, process the request, and then later, instead of broadcasting the context change, responds with a syncerror event in order to reject the request. In this specific case in which the context change is rejected by the Hub and not broadcasted, the syncerror would only be sent to the requestor. The requestor SHALL be capable of gracefully handling a rejected context request.
Once a requested context change is accepted, the Hub SHALL broadcast the context notification to all subscribers, including the original requestor. The requestor can use the broadcasted notification as confirmation of their request. The Hub reusing the request's id is further confirmation that the event is a result of their request.
Last updated: Apr 12 2022 at 19:14 UTC
