Gracefully handle errors in subscriptions. #4473
Conversation
BundleMonFiles updated (1)
Unchanged files (7)
Total files change -74B 0% Final result: ✅ View report in BundleMon website ➡️ |
| @@ -354,12 +365,16 @@ object ProgramCacheController | |||
| val updateConfigurationRequests | |||
| : Resource[IO, Stream[IO, ProgramSummaries => ProgramSummaries]] = | |||
| ProgramQueriesGQL.ConfigurationRequestSubscription | |||
| .subscribe[IO](ConfigurationRequestEditInput(props.programId.assign)) | |||
| .subscribe[IO](ConfigurationRequestEditInput(props.programId.assign))(using | |||
| summon, | |||
There was a problem hiding this comment.
Can the summon be omitted?
There was a problem hiding this comment.
I'll try again, but I don't think so. I think you need something in every position of the using parameter list. The existing subscriptions specifying a error policy are doing this. But, I guess I could maybe just do a given prior to the subscription,
There was a problem hiding this comment.
I was under the impression that Scala 3 was now smart enough to type-match givens in case some were not declared. If that's not the case, just leave the summon.
There was a problem hiding this comment.
I thought so true, so I tried that earlier. It may supposed to be that smart, but apparently it is not.
| val msg = errors.map(_.message).toList.mkString(": ") | ||
| Logger[IO].error(s"Error in subscription: $msg") | ||
|
|
||
| def logAndIgnoreErrors[D]: Pipe[IO, GraphQLResponse[D], D] = |
I'll look and see if I can come up with something more ergonomic. |
I wasn't able to find a nice solution to this. The main issue was that the I will push another commit that shows how that could be used in explore. It, of course, won't compile at this time. |
toddburnside
force-pushed
the
sc-4509-gracefully-handle-error-in-subscriptions
branch
from
a39afb4 to
b5a0f00
Compare
|
Closed in favor of #4477 |
toddburnside
deleted the
sc-4509-gracefully-handle-error-in-subscriptions
branch
If this seems like a good approach we could apply it to other subscriptions as well. Maybe pop a toast if there is no data so the user knows they might be out of date and could reload?
For subscriptions where we regularly expect data + errors, like observations, we could only log in the case of no data. That would clean up the console. Maybe we want to only log for no data for all subscriptions? If there is data, we'll assume we're OK?
I don't expect this situation to happen often (no data). If the ODB is sending a subscription event, it seems like there should be data. But, it was happening for awhile until a bug got fixed in the ODB. Just suddenly going to a big screen of spinning planets is not very user friendly behavior. 😄