You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Publishing a string in to PubSub topic introduces quotes to the message #2204
pull the message and it will have "someMessage" as data
I think this is caused because the message data is being stringified if it is not a Buffer here but I do not think it is the intended behaviour? At least the documentation does not make it clear.
This is intended. We consistently publish messages in JSON format so that a JSON parser on the receiving end has a predictable way to handle the messages it receives. When our library returns the messages, we do a JSON.parse to decode it back to its native JS form:
Thanks for the explanation @stephenplusplus, that explains a lot. The receiving end in my example was written in Ruby. It seems the Ruby API does not expect this behaviour. An alternate service publishing messages to the same queue was written in Python, no problems here. Shouldn't this inconsistency between the different APIs be documented?
I'm glad that cleared it up, and thank you for bringing it up. I don't know of a precedent or requirement that the client libraries are expected to behave the same way, but the fact that you experienced an annoying delay while you tried to figure it out and move on with your app is a good enough reason to me that we should add this in the docs somewhere. I'll keep the issue open and mark with a help wanted label-- feel free to send us a PR if you're up for it!
Activity
stephenplusplus commentedon Apr 11, 2017
This is intended. We consistently publish messages in JSON format so that a JSON parser on the receiving end has a predictable way to handle the messages it receives. When our library returns the messages, we do a JSON.parse to decode it back to its native JS form:
JanPretzel commentedon Apr 11, 2017
Thanks for the explanation @stephenplusplus, that explains a lot. The receiving end in my example was written in Ruby. It seems the Ruby API does not expect this behaviour. An alternate service publishing messages to the same queue was written in Python, no problems here. Shouldn't this inconsistency between the different APIs be documented?
stephenplusplus commentedon Apr 11, 2017
I'm glad that cleared it up, and thank you for bringing it up. I don't know of a precedent or requirement that the client libraries are expected to behave the same way, but the fact that you experienced an annoying delay while you tried to figure it out and move on with your app is a good enough reason to me that we should add this in the docs somewhere. I'll keep the issue open and mark with a help wanted label-- feel free to send us a PR if you're up for it!
stephenplusplus commentedon Apr 11, 2017
Fixed in #2212-- thanks again!
JanPretzel commentedon Apr 11, 2017
Cool! Thank you too!
feat!: Make node 14 the minimum supported version (#2244)
chore: support for common interface to get a session to support multi…
feat!: Make node 14 the minimum supported version (googleapis#2244)