Fix several hot reload issues with subscriptions #7746
Conversation
…iptions Otherwise: - Configuration applies to subscriptions *before* it applies to new requests - Subscriptions may be closed *before* a new schema is warmed up, and reopen while the old pipeline is still active
This comment has been minimized.
This comment has been minimized.
Signed-off-by: Benjamin <5719034+bnjjj@users.noreply.github.com>
✅ Docs preview readyThe preview is ready to be viewed. View the preview File Changes 0 new, 27 changed, 1 removedBuild ID: 440fee943fa08dd92c48c43f URL: https://www.apollographql.com/docs/deploy-preview/440fee943fa08dd92c48c43f |
goto-bus-stop
changed the title
goto-bus-stop
changed the title
goto-bus-stop
changed the title
| fetch_service_factory, | ||
| }; | ||
| } | ||
| Some(_new_configuration) = configuration_updated_rx.next() => { |
There was a problem hiding this comment.
@bnjjj It seems that we're now handling these in the same way. It's not useful to clients to know that a subscription was closed due to a schema or a configuration change (and maybe even desireable that they don't know). Should we just have a single update channel for both updates, and use the SUBSCRIPTION_SCHEMA_RELOAD extension code for both?
There was a problem hiding this comment.
Yes I think we should be let's do this in a follow up PR if you agree, I just want to minimize the impact if possible
There was a problem hiding this comment.
Sure, but clients might treat SUBSCRIPTION_SCHEMA_RELOAD specially, so i think we should at least use the same extension code for both to get the correct behaviour
There was a problem hiding this comment.
I've made that change, I'm fine with keeping the notification system intact and just having that duplicate code for the time being.
When a hot reload is triggered by a configuration change, the router attempted to apply updated configuration to open subscriptions. But this could cause excessive logging.
When a hot reload is triggered by a schema change, the router closed subscriptions with a
SUBSCRIPTION_SCHEMA_RELOADerror. But this happened before the new schema was fully active and warmed up, so clients could reconnect tothe old schema.To fix these issues, a configuration and a schema change now have the same behavior. The router waits for the new configuration and schema to be active, and then closes all subscriptions with a
SUBSCRIPTION_SCHEMA_RELOADerror, so clients can reconnect.Drafted pending a test that verifies that the old behaviour is wrong and the new behaviour is correct. No strong indication yet that this is causing serious problems today, but it should be an improvement.
Checklist
Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.
Exceptions
Note any exceptions here
Notes
Footnotes
It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩
Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩
A lot of (if not most) features benefit from built-in observability and
debug-level logs. Please read this guidance on metrics best-practices. ↩Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩