@andrewsg Looks like there's an example of creating a push subscription added recently; thank you! Where is pubsub_v1.types.PushConfig documented? I can't seem to find it.

Also, any chance there will be an example of updating a subscription?

This might be what I'm looking for, but it seems to suggest that the only thing that can be changed is the push_endpoint: https://googlecloudplatform.github.io/google-cloud-python/latest/pubsub/types.html#google.cloud.pubsub_v1.types.PushConfig

How can I change, for example, the retention duration?

It seems as though there is an example somewhere of updating the ack deadline (though this doesn't show up in the documentation with the other examples).

Hi @foresmac, I looked into this and it looks like retention duration is not configurable for push subscriptions right now.

Other subscription attributes like the topic and ack_deadline_seconds can only be configured on subscription creation; the sub has to be deleted and recreated to change it.

I believe PushConfig (only) can be modified on a live subscription by using an API call: https://cloud.google.com/pubsub/docs/reference/rpc/google.pubsub.v1#google.pubsub.v1.ModifyPushConfigRequest -- so, it looks like you're correct that only the PushConfig attributes are changeable.

If this doesn't meet your needs, please let me know a bit about your use case in a reply and I'll keep track of that.

Well, most specifically, if you have a "bad" message in a topic, and the subscription is set up as push, it'll just keep hitting your endpoint over and over again multiple times per second for seven days—the default retention duration. Now, I know the message is bad, and I've set up ways to prevent the bad message from getting sent to the topic in the future. But I don't want to "fix" the endpoint to deal with this malformed message, and since there's no way whatsoever to monitor topics and remove problematic messages, the only "good" solution is to configure the retention duration to be a more reasonably smaller time interval.

Another possible solution is to engineer every endpoint to basically be a huge try/except block, and do something (log an error, I guess) with the malformed message. Even then, if something somehow causes an uncaught exception, I don't want PubSub to just keep banging away at an endpoint that practically speaking is never going to work. Since it seems unlikely that PubSub is going to radically alter the way it works (an exponential backoff on retries? a management console like AppEngine's task queue?), I'd like to set a more reasonable retention duration, since if I'm not going to change an endpoint in a day, I'm certainly not going to change it in seven.

@andrewsg Does that make sense?

Yes, it does! Thank you for the feedback. I will send this along to our product manager.

Hi @foresmac, update here, my product manager says that the ability to customize the retention period for push subscriptions is in alpha right now. If you would like to participate, reach out at [email protected].