If you have to update a subscription's settings (like changing a filter), then the subscription needs to be recreated. The risk here is that, in production, there could be messages pending so the developer has to stop the publisher and allow the subscription to clear before deleting it and recreating it, resulting in some down time.
It would be helpful to have a feature that could "migrate" one subscription to another. So for example, I would create the new/updated subscription and then ask PubSub to move any unprocessed message from the old one to the new one. There would still be an update required to change the subscription in the app, but this would likely be much faster.
Some other ideas:
- Have google manage the migration, introducing an "update" function that, under the hood, creates an inactive subscription with the same name (obviously there'd be some dance to to go through here because you can't have the same name), moves the messages, deactivates the old subscription and then brings the new one up, so no changes are necessary to the app. The app would briefly lose connection but the SDK would manage the reconnect.