Handling Pubsub messages in Google Functions

Question

I'm learning about the Google cloud functions and I'm setting them up to be triggered by the messages placed in the queue. I think I'm really failing to grasp some concepts here as I have a bunch of questions and can't find answers anywhere. There are a lot of examples explaining functions and clients, but I haven't found examples merging the two.

1. Functions get triggered by the topic and not by the subscription. This one is weird because as a single topic can have multiple subscriptions and even multiple subscribers per subscription, this would mean the function doesn't acknowledge the messages as it doesn't know which message to acknowledge.

2. Building on the first question, when a message arrives on the topic, do all the subscriber functions get executed? What about the functions that are in the process of doing some work? What about multiple subscribers on a single subscription?

3. Can a real pull subscription then even be implemented in a function? That would mean the function runs constantly because of the need to pull the items, which is costly and the wrong thing to do.

4. Can a message be nacked from the function? It seems the functions are retried only if they are deployed with allowing retries turned on, but then they try to rerun the function immediately and for as long as the retry period is set (default is 7 days) which can cause extreme costs if a function is buggy, and is a totally crap pattern.

All of this makes me think that:

1. It would be much better implementation to trigger functions from subscriptions and for subscriptions to be able to ack / nack them than listening to topics

2. I should choose push subscriptions alongside HTTP functions, which seem much more controllable (I might be wrong, haven't tried it)

Can anyone shed some light on this? Can I control the messages easily from the function and can I expect the function to be rerun if a message is nacked or resent?

Answer 1

1. Perhaps the piece of information that is key is that when you hook a Cloud Pub/Sub topic to a Cloud Function, a push subscription is created by the system in order to send messages to that Cloud Function.

2. Every cloud function you tie to a topic will have its own subscription and will receive all messages published to the topic. If an instance of the function is already doing work, then another instance could be created to handle the load (or will just be load balanced among instances that are already running). Push subscriptions don't really have a notion of multiple subscribers for the same subscription. From Cloud Pub/Sub's perspective, there is a single endpoint to which to push messages. Cloud Functions receives those messages and distributes them among instances of your Function that the service is running.

3. It would be very tough to implement a pull subscription as a Cloud Function. You would need a trigger to start the Function and it would have to do all of its work in the time allotted for it to run.

4. It sounds like you want to nack with a backoff on retrying the message. That is not a feature supported currently, but we are aware of the limitation and are looking to make improvements here soon.