Google-cloud-go: Consider making PubSub `Message.ackID` public

[lc-chrisbarton]

PubSub

We would like to log the Message.ackID so we can use it with the gcloud command-line tools to directly ack/nack messages that appear in our error logs

[jadekler]

Out of curiousity, what's the advantage of gcloud acking/nacking instead of the client library doing so? o.O

[lc-chrisbarton]

Well occasionally it takes some investigation to understand why a message cannot be processed and if it should be removed. This happens to us every few months with data sent by external parties. It happened today and it is very convenient to be able to use tools to do some surgery on the subscription.

[jadekler]

Makes sense - thanks for satisfying my curiousity!

[lc-chrisbarton]

See https://github.com/googleapis/google-cloud-go/issues/454

[hongalex]

@jadekler Personally, I'm in favor of this change. It increases our API surface a bit, but ultimately could be useful for reason as @lc-chrisbarton has mentioned.

AFAICT, this can be simply fixed by a one-line change on message.go. Is there anything else I might be missing (or that we need to test) to make this change safe?

[jadekler]

Seems reasonable to me. Do other languages do so? If we make it public here I suspect it should be public everywhere.

cc @kamalaboulhosn

[kamalaboulhosn]

@hongalex @jadekler We should not make ackID public in the client libraries. There are implications if someone acks out-of-band. The message will still count against flow control until the modack period has expired. If this is done with enough messages, the subscriber may stop getting message entirely. Given the prescriptive nature of the client libraries, I don't want to expose more than needs to be.

With regard to the original issue, it sounds like the problem is a "poison pill" message that doesn't adhere to the expected message type or something of that nature. We are investigating adding some features to Pub/Sub as a whole that are designed specifically to deal with this case.