PubSub Message does not allow numbers

[tacticurv]

If the JSON object in the attributes contains a number, an error is thrown as follows.

Step 3 : Error  Error: Illegal value for [object Object] of type string: number (not a string)
                 at Error (native)
                 at fail (.../node_modules/google-cloud/node_modules/protobufjs/dist/protobuf.js:1801:23)
                 at Element.ProtoBuf.Reflect.ElementPrototype.verifyValue (.../node_modules/google-cloud/node_modules/protobufjs/dist/protobuf.js:1863:25)
                 at new Map (.../node_modules/google-cloud/node_modules/protobufjs/dist/protobuf.js:4942:46)
                 at T.ProtoBuf.Reflect.FieldPrototype.verifyValue (.../node_modules/google-cloud/node_modules/protobufjs/dist/protobuf.js:3465:28)
                 at MessagePrototype.set (.../node_modules/google-cloud/node_modules/protobufjs/dist/protobuf.js:2475:59)
                 at MessagePrototype.set (.../node_modules/google-cloud/node_modules/protobufjs/dist/protobuf.js:2466:38)
                 at Message (.../node_modules/google-cloud/node_modules/protobufjs/dist/protobuf.js:2395:34)
                 at Element.ProtoBuf.Reflect.ElementPrototype.verifyValue (.../node_modules/google-cloud/node_modules/protobufjs/dist/protobuf.js:1909:28)
                 at T.ProtoBuf.Reflect.FieldPrototype.verifyValue (.../node_modules/google-cloud/node_modules/protobufjs/dist/protobuf.js:3455:43)

Environment details - From where the message was generated

• OS: Ubuntu 14.04
• Node.js version: 6.9.2
• npm version: 3.10.9
• google-cloud-node version: 0.45.1

Steps to reproduce

1. require google-cloud
2. topic.publish({data : "...", attributes : message}, options, function(err) {
   ...
   });
   where message is a JSON object and options have raw enabled to true.

[stephenplusplus]

The attributes for a message are required as a map with string values by the upstream API. We could stringify values for the user, but that would probably be unexpected. Also, we wouldn't be able to reverse the stringified value when parsing an attributes object, as we wouldn't have any record of what was stringified or not.

I think the safest bet is for a user is to simply handle the stringify process themselves. I'm going to close, but let me know if I'm overlooking something and there is a better solution.

[tacticurv]

Thanks for citing the API. I can't think of any other solution. Even if the message is appended with type definitions that can be use to parse it when delivered, it is only helpful in pull based messaging as the client library handles the parsing of data, but it wouldn't be much useful in push based delivery.

However I think the documentation needs to be updated here. It is misleading as the sample message has a "userId" key with a number value.

[stephenplusplus]

That is part of the message that is the data itself, but is not an attribute for the message. Data objects are much more flexible in regards to the supported types.