Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-36993

When should the Hub start ignoring that a web socket was closed?

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • FHIRCast (FHIR)
    • 2.1.0-ballot [deprecated]
    • Infrastructure & Messaging
    • FHIRcast Observation
    • Event notification [deprecated]
    • 2.5
    • Hide

      We will retain the existing requirement in the specification that:
      >Upon communicating a syncerror resulting from an unresponsive app, the Hub SHALL unsubscribe the application.

      here: https://build.fhir.org/ig/HL7/fhircast-docs/2-5-EventNotification.html#hub-generated-syncerror-events

      Show
      We will retain the existing requirement in the specification that: >Upon communicating a syncerror resulting from an unresponsive app, the Hub SHALL unsubscribe the application. here: https://build.fhir.org/ig/HL7/fhircast-docs/2-5-EventNotification.html#hub-generated-syncerror-events
    • Catie Ladd / Nick Radov : 5-0-1
    • Clarification
    • Non-substantive

    Description

      When should the Hub start ignoring that a web socket was closed? Immediately (i.e. return no error to the user)? Or return an error once to the user, and remove the subscription immediately at that moment? Or should the error be returned for every context change? But when does it stop? At some moment we can expect the user to know that something went wrong. So my suggestion would be to discard closed WebSocket connections after displaying an error to the user once that an app is no longer reachable (and didn’t unsubscribe).

       

      Attachments

        Activity

          People

            Unassigned Unassigned
            eschnell Evan Schnell (Inactive)
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: