Google-cloud-go: pubsub: puller requires more permissions than it should for acker

[imkira]

So I decide to create a service account with absolutely no IAM roles defined, and then I added the Pub/Sub Subscriber permission to some subscription, which fails to authorize with google-cloud-go when I call subscription.Pull. If I add the Pub/Sub Viewer permission then, all of a sudden, it starts working.
This left me wondering because google-cloud-java works with just the Subscriber permission.

At close inspection, I noticed Pull is trying to get the subscription configuration (so requiring the Viewer permission would make sense).

https://github.com/GoogleCloudPlatform/google-cloud-go/blob/3c4c8cc11d151d76587802cb55dd7b80beca832b/pubsub/subscription.go#L141

But then, I wondered how were the java guys doing it, which seems to be like this.

https://github.com/GoogleCloudPlatform/google-cloud-java/blob/0a5a27f067ee4b649148ea90974b6536a7f5b671/google-cloud-pubsub/src/main/java/com/google/cloud/pubsub/AckDeadlineRenewer.java#L191

So apparently they are not requesting the subscription's config for getting the ack deadline option, but rather fetching messages and acking with a delay that depends on the current message's expected ack deadline (which looks smarter, albeit more complex).

I am writing this issue to first ask you if you were aware of this and/or if this is a design decision. Secondly, if you were OK with accepting a PR that would remove the retrieval of the subcription's config and use the next message's expected ack deadline, similar to what the java client does?

[pongad]

The Java StreamingPull implementation records the message-acking latency in a distribution. It periodically sets the message deadline to the 99th percentile. We can do the same in here and it will naturally make the viewer permission unnecessary.

I'll prioritize this at P2 since the current implementation still works if you're OK with the additional role.

[lopezator]

Same here. Lost all the day fighting against this as well.

[glerchundi]

Same here, unable to make it work until I realised that editor worked...and finally discovered that an issue was already filed.

[jba]

We still call Subscriber.Config, so this isn't quite fixed yet.