FHIR Chat · Sept 2020 Virtual Connectathon · subscriptions

Stream: subscriptions

Topic: Sept 2020 Virtual Connectathon

Jenni Syed (Jul 20 2020 at 23:09):

Just a heads up that we will be having a Subscription track again this connectathon. I already have it set up to cover the newer R5 features and the patch back proposal. Are there other topics people would like to see?

Isaac Vetter (Aug 26 2020 at 20:30):

Hey Jenni! We're hoping to participate in the Sept FHIR Subscriptions track to evaluate Carequality's use of the r4 backport. Still planning on an orientation calls? @Spencer LaGesse

Jenni Syed (Aug 26 2020 at 21:49):

Yes, I'll be putting together the new template slides and getting a time set very soon :) (look for announcement before end of week)

Jenni Syed (Aug 27 2020 at 17:52):

The connectathon prep meeting will be Tuesday, Sept 1st from 13:00-14:00 America/Central. Details and an ics can be found on the track page: https://confluence.hl7.org/display/FHIR/2020-09+Subscriptions+Track

Jenni Syed (Sep 01 2020 at 18:58):

Hey all - the recording is now uploaded out on the track's confluence page for those that missed it! Keep in mind that there's a general Connectathon prep session today at 4PM Eastern time/3PM Central which will go over Whova and other general info

Jenni Syed (Sep 01 2020 at 18:59):

Remember to fill out the survey, so we know who will be involved with the track (and time zones!) in order to plan our kickoff and checkin times: https://www.surveymonkey.com/r/6R3LFFM

Jenni Syed (Sep 01 2020 at 18:59):

And finally: the big question

Jenni Syed (Sep 01 2020 at 19:00):

If you're bringing a client app to test (or server), are you planning on focusing on R5? Backport to R4? WebSockets? It may help determine what implementers focus on prior to the connectathon!

Jenni Syed (Sep 01 2020 at 19:01):

Right now, participants seem to be focusing on the backport this time around (based on the small group that was able to make the call)

Spencer LaGesse (Sep 02 2020 at 20:14):

I'm planning on bringing at least an R4 backport client that does rest-hook only.

Avery Allen (Sep 08 2020 at 16:29):

Hey all, I'm hoping to get a conversation started around the SubscriptionTopic List Operation that's part of the R5 Backport IG:

http://build.fhir.org/ig/HL7/fhir-subscription-backport-ig/OperationDefinition-Backport-subscriptiontopic-list.html

@Jenni Syed mentioned that she thought topic search wasn't going to be available in a patch back, but I see that the Argo test client is using for R4 workflows:

https://subscriptions.argo.run/

https://github.com/microsoft-healthcare-madison/argonaut-subscription-client-ui/blob/0bb402e51d8c5a90c89b854a227a0ae86cfa24c0/src/util/TopicHelper.ts#L33

Jenni Syed (Sep 08 2020 at 18:54):

cc @Gino Canessa - I didn't realize we ended up patching back more than "minimum viable" and wasn't sure when/why etc :)

Gino Canessa (Sep 08 2020 at 19:27):

I think the goal is still "minimum viable", @Jenni Syed ... it just depends on who is defining that :-).

The scope still isn't set in stone - I haven't received any feedback one way or the other. If people feel it's too large/small, I'm happy to update it.

David Pyke (Sep 08 2020 at 19:28):

I've merged a lot of your work into the Carequality IG, as soon as we meet to review, I'll give you feedback.

Jenni Syed (Sep 08 2020 at 19:36):

I think we originally thought topic could just be an agreed upon known URL for R4 and that the choice of moving to R4 came with functional sacrifices :)

Jenni Syed (Sep 08 2020 at 19:40):

Based on:
"It is ok to target to specific use case needs
Limit to RestHook and email (public health and ADT notifications, DaVinci needs fit here)
The SubscriptionTopic agreement can be out of band - not dynamic as R5 allows today.
limit to id-only and empty"

From May 15th summary: https://chat.fhir.org/#narrow/stream/179229-subscriptions/topic/any.20work.20backporting.20r5.20subscriptions.20to.20r4.3F/near/197758822

Jenni Syed (Sep 08 2020 at 19:41):

I have serious hesitation taking it to a "fully functional R5 on R4" since that makes implementing it pretty hard

Gino Canessa (Sep 08 2020 at 20:04):

I agree, trying to move all the functionality in doesn't make a lot of sense. Right now there is nothing about topics beyond listing them (e.g., you can't even get an actual representation of them).

Jenni Syed (Sep 09 2020 at 17:05):

For those of you attending... quick vote:

Jenni Syed (Sep 09 2020 at 17:05):

/poll When should we kick off tomorrow?
9AM ET
10AM ET

Jenni Syed (Sep 09 2020 at 17:06):

9 AM seems mean if we have people on Pacific time...

Grahame Grieve (Sep 09 2020 at 17:23):

either is mean ;-)

Jenni Syed (Sep 09 2020 at 17:24):

Hey, no Aussies said they were participating on here :rolling_on_the_floor_laughing:

Jenni Syed (Sep 09 2020 at 17:25):

Also, isn't it like 3AM there right now?? Goodness

Jenni Syed (Sep 09 2020 at 17:26):

(also, if we do have international participation on this track, just let me know time zones and I'm fine with doing 2 kickoffs - would be cool if we could do 1 "wrap up")

David Pyke (Sep 09 2020 at 17:26):

Grahame doesn't do clocks. He hasn't slept since 2012

Grahame Grieve (Sep 09 2020 at 17:31):

I am moving my sleep forward several hours for the connectathon. but don't try and find a time that suits me. I'll just keep up as I can

Jenni Syed (Sep 09 2020 at 21:12):

So far the winner for the kick off is 10AM ET (I'll still start the call at 9AM ET for those of you who are on)

Grahame Grieve (Sep 09 2020 at 23:14):

I have a question about this track - what's the expectation around SubscriptionTopic? That we jsut announce fixed ones in advance? or that participants should be able to find topics by search?

Grahame Grieve (Sep 09 2020 at 23:19):

@Gino Canessa the track recommends the use of build.fhir.org, but there is a connectathon stable snapshot at http://hl7.org/fhir/2020Sep - have you made any changes to the build.fhir.org since I published the snapshot?

Grahame Grieve (Sep 10 2020 at 01:05):

Another question for Gino. Quoting from build.fhir.org:

TODO
Updates to "Managing Subscriptions and Errors"

• Discuss error codes (Extensible Codeable Concept)
• Define basic error codes here
• Need to discuss eventCount and error detection (insert appropriate examples/workflows)
• Updates to "Tracking Subscription Notifications" SHOULD define what the AuditEvent looks like

and also

If the notification fails, the server SHOULD set the status to error and mark the error in the resource

Is there any arrangements about this for the connectathon?

Gino Canessa (Sep 10 2020 at 01:20):

No, there haven't been any changes. Likely just copy pasta.

Gino Canessa (Sep 10 2020 at 01:23):

I don't think there's anything specific on those topics (@Jenni Syed ?). Several of those items are from early-on in the redesign process, so we need to evaluate if the are actually tasks (and if they are, do them).

Grahame Grieve (Sep 10 2020 at 01:24):

copy pasta sounds better for sure

Jenni Syed (Sep 10 2020 at 01:41):

The scenarios do call out a requirement for servers to support search on topics for the r5 version

Jenni Syed (Sep 10 2020 at 01:42):

However, based on original interest, I suspect people will dig far more into the patch back to r4 rather than getting into the detailed questions listed above for r5

Grahame Grieve (Sep 10 2020 at 01:43):

hmm. maybe I'll change my focus

Grahame Grieve (Sep 10 2020 at 02:07):

What should happen to criteria in the backport to R4? the IG appears to be silent about this

Gino Canessa (Sep 10 2020 at 02:16):

In the backport, Subscription.criteria serves as a replacement for the R5 Subscription.filterBy component.

Gino Canessa (Sep 10 2020 at 02:17):

So having text like Encounter?patient=Patient/123 would be logical (assuming the topic allowed that filter)

Grahame Grieve (Sep 10 2020 at 02:20):

I'm glad I asked. Encounter?patient=Patient/123 is not equivalent to Subscription.filterBy because of the presence of Encounter?

Gino Canessa (Sep 10 2020 at 02:35):

I'm not 100% sure why I ended up with that (can't find the right keywords for zulip search). I believe it was to make them 'fit' better with R4. I'm certainly not tied to that syntax.

Grahame Grieve (Sep 10 2020 at 02:37):

it's very relevant for me right now, because I'm grappling with the fact that my implementation is based around a subscription being for a single resource. The fact that a topic can be for multiple resource types is challenging me. And one of the manifestations of that challenge is that the R subscription has filter parameters but for which of the types?

Grahame Grieve (Sep 10 2020 at 02:37):

that relates to the use of criteria, obviously

Gino Canessa (Sep 10 2020 at 02:40):

Ah, that was it - SubscriptionTopic.resourceTrigger.resourceType is 0..*. So, I used that syntax: {resourceType}?{searchParamName}{searchModifier}={value}.

Gino Canessa (Sep 10 2020 at 02:41):

That makes the requested subscription look like:

{
  "resourceType": "Subscription",
  "end": "2020-09-10T03:41:05.458Z",
  "reason": "Client Testing",
  "channel": {
    "endpoint": "https://client.subscriptions.argo.run/Endpoints/bbf5131c-8a0a-452f-946c-032c632ac2a9",
    "payload": "application/fhir+json",
    "_payload": {
      "extension": [
        {
          "url": "http://hl7.org/fhir/us/subscriptions-backport/StructureDefinition/backport-payload-content",
          "valueCode": "id-only"
        }
      ]
    },
    "type": "rest-hook",
    "extension": [
      {
        "url": "http://hl7.org/fhir/us/subscriptions-backport/StructureDefinition/backport-heartbeat-period",
        "valueUnsignedInt": 60
      }
    ]
  },
  "status": "requested",
  "criteria": "Encounter?patient=Patient/39917",
  "extension": [
    {
      "url": "http://hl7.org/fhir/us/subscriptions-backport/StructureDefinition/backport-topic-canonical",
      "valueCanonical": "http://argonautproject.org/encounters-ig/SubscriptionTopic/encounter-start"
    }
  ]
}

Gino Canessa (Sep 10 2020 at 02:43):

If you are working on your server, the implementation at subscription.argo.run has the backport (as it is currently) implemented.

Grahame Grieve (Sep 10 2020 at 02:52):

thanks but that doesn't explain for me what criteria looks like if the topic has more than one type. Can the subscription only be for one type?

Gino Canessa (Sep 10 2020 at 02:54):

Right now I believe that's a limitation. I'd be happy to add a syntax for it - comma separated like other 'multi-value' fields? Otherwise, we need to load in some text for the field and add another extension. I don't know that I have a strong preference one way or the other.

Grahame Grieve (Sep 10 2020 at 03:01):

yeah I don't know. I think there's use cases for multiple different resource types.... so i think we need to solve if. both in R4 and R5.

Grahame Grieve (Sep 10 2020 at 03:03):

we could define an extension for R4, but then we'd be left with a useless element hanging arount. Or we could say that it just lists the resource types, and resource specific search criteria are in extensions. or we could just invent a hick syntax and stuff it all inside criteria.

All roughly equally meh

Gino Canessa (Sep 10 2020 at 03:04):

In R5 it should be simple, since Subscription.filterBy is 0..*, all we need to do is add resourceType to that component.

Grahame Grieve (Sep 10 2020 at 03:04):

"criteria" : "Encounter?param=value | EpisodeOfCare?param=value",

Gino Canessa (Sep 10 2020 at 03:05):

Ugh. Either | or , is going to be a pain to parse, since those are both valid in the values themselves.

Grahame Grieve (Sep 10 2020 at 03:08):

spaces...

Gino Canessa (Sep 10 2020 at 03:09):

For single resource type, criteria feels optimal... maybe leave the {resourceType}?{searchParamName}{searchModifier}={value} syntax, and add an extension on criteria for additional ones:

"criteria": "Encounter?patient=Patient/39917",
"_criteria": {
      "extension": [
        {
          "url": "http://hl7.org/fhir/us/subscriptions-backport/StructureDefinition/backport-additional-criteria",
          "valueString": "Observation?patient=Patient/39917"
        }
      ]
    }

Grahame Grieve (Sep 10 2020 at 03:09):

that's a 4th option which is meh. Which one goes in the root criteria?

Gino Canessa (Sep 10 2020 at 03:10):

Grahame Grieve said:

spaces...

I instinctively ignore whitespace ;-). But, that could work

Gino Canessa (Sep 10 2020 at 03:11):

Grahame Grieve said:

that's a 4th option which is meh. Which one goes in the root criteria?

Whichever - there's no order implied by the triggers, so it shouldn't matter.

Grahame Grieve (Sep 10 2020 at 03:12):

well, I dislike all of them roughly equally. Do you have a strong preference?

Gino Canessa (Sep 10 2020 at 03:13):

I'm in the same boat - they all feel a little clunky, but serviceable.

Grahame Grieve (Sep 10 2020 at 03:19):

Need to add resource type to SubscriptionType.canFilterBy too

Grahame Grieve (Sep 10 2020 at 03:22):

what goes in SubscriptionTopic.resourceTrigger.queryCriteria.current etc? is that more search parameters?

Gino Canessa (Sep 10 2020 at 03:24):

Yes it is. It may be clearer to change resourceType to 0..1 and make resourceTrigger 0..*, so each trigger is only for a single resource.

Grahame Grieve (Sep 10 2020 at 03:24):

ah it is. so then, search parameter names go in

• SubscriptionTopic.resourceTrigger.queryCriteria.*
• SubscriptionTopic.canFilterBy.searchParamName
• Subscription.filterBy

Grahame Grieve (Sep 10 2020 at 03:25):

may be clearer to change resourceType to 0..1 and make resourceTrigger 0..*

Clearer, definitely. But not necessarily nicer. For a server like mine, totally FHIR based, that'd be sweet. But if you are fitting this onto an internal storage trigger system, it ciuld be unfortunate. I thought that was explicitly why we make it 0..*

Gino Canessa (Sep 10 2020 at 03:28):

How are the two different, other than parsing logic?

Grahame Grieve (Sep 10 2020 at 03:32):

oh. whoops. I didn't finish reading the sentence.

Grahame Grieve (Sep 10 2020 at 03:32):

I agree with that, and to move canFilterBy under resourceTrigger

Gino Canessa (Sep 10 2020 at 03:32):

I can get behind that

Grahame Grieve (Sep 10 2020 at 03:33):

anyway, back to search parameter names, I'm wondering whether there's use cases for these search parameters to appear in the search:

• _id - yes
• _lastUpdated - ?
• _tag - yes
• _profile - yes
• _security - yes
• _text - ?
• _content - no?
• _list - yes ( :frown: )
• _has - no (hoping...)
• _type - no (because of the rest of this discussion...)
• _filter - no (hoping)

I'm interested in people's opinions here....

Grahame Grieve (Sep 10 2020 at 03:33):

and have we talked about chaining on search parameters?

Gino Canessa (Sep 10 2020 at 03:35):

We've talked about chaining, I believe the general feel was to disallow it. I have a note to reference FhirPath Simple and find similar restrictions on they query parameters.

Grahame Grieve (Sep 10 2020 at 03:38):

I certainly like not chaining; it's a big integrity issue.

Grahame Grieve (Sep 10 2020 at 03:38):

referencing FHIRPath simple won't work though

Gino Canessa (Sep 10 2020 at 03:49):

Yeah, it's still a little wide. It's still on my list because it's annoying to sort through.

Gino Canessa (Sep 10 2020 at 03:52):

But, I've finished everything else I was planning on doing tonight so I'm going to get some sleep. Have a good night!

Josh Mandel (Sep 10 2020 at 13:31):

In previous discussions about chaining we concluded that this would be allowed in the syntax but individual servers would decide where to support it, as in search.

David Pyke (Sep 10 2020 at 13:34):

Many of the people I've talked with feel the computational load for search and FHIRPath based topics is too high to be supported. Many are expecting to have thousands or tens of thousands of subscriptions simultaneously and want to maintain a reasonable response time (<5 minutes).

Josh Mandel (Sep 10 2020 at 13:37):

I am going to break discussions out into separate Zulip topics :-)

David Pyke (Sep 10 2020 at 13:38):

As long as it's 0..1/* and can be specified via the CapabilityStatement what is supported, it's fine.

Jenni Syed (Sep 10 2020 at 13:44):

Topics Josh kicked off that we'll be discussing: https://chat.fhir.org/#narrow/stream/179229-subscriptions/topic/Fhirpath.20triggers

Jenni Syed (Sep 10 2020 at 13:44):

https://chat.fhir.org/#narrow/stream/179229-subscriptions/topic/Modeling.20resource.20triggers

Gino Canessa (Sep 10 2020 at 13:47):

FYI: a (rough) walkthrough of using the test implementation (subscriptions.argo.run) is available on YouTube. A note a forgot to make in the video - all FHIR calls are done in the browser, so you can load the page and still work with a local server.

Cheers!

Avery Allen (Sep 10 2020 at 14:14):

Here's info on how to use Cerner's R4/R5 Subscription server:

https://github.com/averyallen/wgm_notes/tree/sept_2020

Jenni Syed (Sep 10 2020 at 14:48):

/poll What time should we do a sync this afternoon?
3:00 ET
4:00 ET
5:00 ET

Jenni Syed (Sep 10 2020 at 15:56):

DevDays presentation, let's build by Gino: https://www.devdays.com/wp-content/uploads/2019/12/Gino-Canessa-Lets-Build-Subscriptions-_-DevDays-2019-Amsterdam.pdf

Jenni Syed (Sep 10 2020 at 15:56):

Subscriptions presentation by Gino: https://www.devdays.com/wp-content/uploads/2019/12/Gino-Canessa-Subscriptions-_-DevDays-2019-Amsterdam.pdf

Cary (Sep 10 2020 at 15:59):

@Jenni Syed Those are both the same link, I think maybe you accidentally pasted the same one? The presentation video is missing I think

Gino Canessa (Sep 10 2020 at 16:01):

As a note, I also keep the link aka.ms/devdays-gino up to date with presentations from DevDays (it's a link to a OneDrive folder with PowerPoints in it, for anyone who has VPN/access issues).

Jenni Syed (Sep 10 2020 at 16:09):

Those are the 2 links (one has "let's build" in the tilte, the other doesn't)...

Jenni Syed (Sep 10 2020 at 16:09):

Maybe it didn't have the video part published...

Cary (Sep 10 2020 at 16:10):

Ah sorry, my bad, okay thanks

Jenni Syed (Sep 10 2020 at 16:10):

wait, there are videos in another part... just a sec

Jenni Syed (Sep 10 2020 at 16:11):

https://youtu.be/XybJ1WTuh_o

Jenni Syed (Sep 10 2020 at 16:11):

https://www.devdays.com/events/devdays-europe-2019/ Is where I'm finding all these :)

Jenni Syed (Sep 10 2020 at 16:12):

This is mine from the US DevDays: https://www.youtube.com/watch?v=tnWxOI_wtk4

Cary (Sep 10 2020 at 16:13):

Yay! Thank you very much!

Jenni Syed (Sep 10 2020 at 16:18):

BTW - I'm stepping away from the call for some food :)

Jenni Syed (Sep 10 2020 at 16:52):

It looks like 5 ET is the winner for our wrap up today!

Jenni Syed (Sep 10 2020 at 18:59):

FYI: I have to step away from the zoom session for another meeting

Jenni Syed (Sep 10 2020 at 20:38):

Another topic needing feedback from the call this morning: https://chat.fhir.org/#narrow/stream/179229-subscriptions/topic/Accuracy.2Fatomicity.20of.20eventsSinceSubscriptionStart

Jenni Syed (Sep 10 2020 at 20:46):

Reminder that we have our wrap up for the day in 15 minutes!

Grahame Grieve (Sep 10 2020 at 20:59):

what's the link?

Jenni Syed (Sep 10 2020 at 21:00):

It's just on the normal whova track

Jenni Syed (Sep 10 2020 at 21:00):

no special breakout

Jenni Syed (Sep 10 2020 at 21:00):

I've been warned not to post zoom links here... :D

Josh Mandel (Sep 10 2020 at 21:01):

https://whova.com/portal/webapp/hlfhi_202009/Agenda/1212542

Jenni Syed (Sep 10 2020 at 22:10):

I've been slowly building up a report out, feel free to correct where I forgot/couldn't find/got your name and/or company wrong (or PM me if you can't edit or don't want to). I built this primarily via Zoom participants + registration in ConMan or in Zulip: https://confluence.hl7.org/display/FHIR/2020-09+Subscriptions+Track#id-202009SubscriptionsTrack-Participants

Jenni Syed (Sep 10 2020 at 22:10):

Reminder that we'll kick off again tomorrow at 10AM ET

Jenni Syed (Sep 11 2020 at 13:57):

Kicking off in 3 minutes!

Jenni Syed (Sep 11 2020 at 14:47):

I've updated the report out section of the confluence page with information from last night and this morning. I'm hoping to keep this up to date. As always, if you want something changed/updated you can feel free to edit or PM me and let me know what you want updated.

Jenni Syed (Sep 11 2020 at 14:48):

On that same thread... I propose a quick synch up today at 3 ET. If you have a client, and want to do a quick demo of what you achieved, we can do that informally at that time

Jenni Syed (Sep 11 2020 at 14:49):

/poll Does 3 ET work as a quick status check today?
Yes
Nope

Jenni Syed (Sep 11 2020 at 14:50):

Also, if you want to demo your server, we can do that as well!

Grahame Grieve (Sep 11 2020 at 16:17):

hey @Gino Canessa a reference like this: http://argonautproject.org/encounters-ig/SubscriptionTopic/encounter-start - does it actually exist? do we have any actual topics for the connectathon?

Gino Canessa (Sep 11 2020 at 16:19):

Yes, that was the format used for the canonical URL. It defined in the Argonaut Encounter IG (not a "full published HL7 IG") that lives on GitHub. The resource definitions are linked in the doc as well: encounter-start and encounter-end

Jenni Syed (Sep 11 2020 at 16:32):

This was posted in Whova by @Silas Johnson and I'm moving it here:

1. Best practices/solutions for handling when the FHIR Subscription hook is down. - Caching/queueing request etc.
2. Is any one using The "Smart-On-FHIR" profile for OAuth and is it ready for primetime?
3. If the rest hook rejects the payload (e.g., validation errors), is there any plans for notifications regarding these kind of events?

Grahame Grieve (Sep 11 2020 at 16:33):

hmm #1 looks like the same as #3 ?

Jenni Syed (Sep 11 2020 at 16:34):

For issue 2: I assume in the context of Subcriptions? Most servers live in the wild use this already today. @Avery Allen did we put auth on top of Subscription create so that @Silas Johnson can try it out?

Avery Allen (Sep 11 2020 at 16:36):

Jenni Syed said:

For issue 2: I assume in the context of Subcriptions? Most servers live in the wild use this already today. Avery Allen did we put auth on top of Subscription create so that Silas Johnson can try it out?

We have not done that, but I can look into getting it set up.

Jenni Syed (Sep 11 2020 at 16:36):

@Grahame Grieve yeah, I'm not sure. Would need @Silas Johnson to confirm. The SubscriptionStatus resource provides error state information as well as a count of notificatioons that the server thinks were sent. The application can query this from the operation to get what the FHIR server thinks the current state is: http://build.fhir.org/subscriptionstatus.html#query-status

Jenni Syed (Sep 11 2020 at 16:36):

There's also a heartbeat described in the spec so that the client can detect connectivity issues

Gino Canessa (Sep 11 2020 at 16:47):

re: 1.: Currently, the spec says:

The server may retry the notification a fixed number of times and/or refer errors to its own alert logs. If the notification fails, the server SHOULD set the status to error and mark the error in the resource. If the notification succeeds, the server SHOULD update the status to active and may remove any error codes. If a subscription fails consistently a server may choose set the subscription status to off and stop trying to send notifications.

Errors a server wishes to make accessible to clients are stored in Subscription.error. Servers should provide a mechanism for clearing errors (e.g., when resetting a Subscription.status back to requested after an error). Since Subscription.error represents server errors, a server SHOULD NOT allow clients to add errors.

I don't know if we can go as far as saying that a server should queue the requests (that goes into the reliable delivery territory).

Grahame Grieve (Sep 11 2020 at 16:51):

it's hard to process that language since 'error' has been removed

Gino Canessa (Sep 11 2020 at 16:51):

Yep, but I have to quote what's there instead of what's updated in my head :-)

Spencer LaGesse (Sep 11 2020 at 16:53):

Is there a way for a client to get a list of missed notifications?

Josh Mandel (Sep 11 2020 at 16:54):

None built in (though we've discussed how defining a specific operation for this could help, there hasn't been much interest in developing this idea). Instead, for now we just have the idea that on specific topics, there are "catch-up queries" a client may be able to run (e.g., for an admissions topic, clients can catch up on missed messages or recover from errors by querying for recent encounters).

Jenni Syed (Sep 11 2020 at 17:27):

There are a list of errors

Jenni Syed (Sep 11 2020 at 17:27):

in the status side

Jenni Syed (Sep 11 2020 at 17:28):

but yes, catch up queries is the approach once you've detected something wrong

Jenni Syed (Sep 11 2020 at 18:35):

Reminder, we have our afternoon sync in 25 minutes!

Spencer LaGesse (Sep 11 2020 at 18:58):

What about a way to detect duplicate notifications? I'm not seeing any good way to differentiate between duplicate notifications and multiple legitimate notifications for the same resource.

Jenni Syed (Sep 11 2020 at 19:00):

The version on the resource, if you're looking for changes, would be one way

Jenni Syed (Sep 11 2020 at 19:01):

some client apps actually "batch up" notifications b/c they don't want to process back to back if multiple changes happen (there are processes that could trigger this... also if you watch something that is fed in by a machine the alert notification is pretty heavy)

Last updated: Apr 12 2022 at 19:14 UTC