Gotcha, so the index value of 100 is not a non-standard value.

So I'm seeing "invalid wire type" when using the decode method of 
protobuf.js of an AMQ body.  This is in a Node using the protobuf.js, 
stomp-client.js and an AMQ broker.

The GPB that I'm using has a basic format of this:

syntax = "proto2";
package testt;
message Monkey
{
  optional string timestamp = 1;
}
message TestResponse
{
  optional Monkey header = 100;
  optional string mykey = 2;
  optional string myvalue = 3;
}

And the message is encoded and sent to the broker like this:

// note TestRespGPBDef is created earlier
let payload = {
  header: {
  timestamp: 'monkeybutt'
  },
  mykey: 'hi',
  myvalue: 'there'
};
let verifyErr = TestRespGPBDef.verify(payload);
if( verifyErr ) {
  console.log(`GPB OBJECT/PAYLOAD ERROR`, {verifyErr});
  return;
}
let gmsg = TestRespGPBDef.create(payload);
let buff = TestRespGPBDef.encode(gmsg).finish();
let str = buff.toString();
stompClient.publish('mytopic',str);


And the message is rd'x and decoded by the consumer like this:

// note TestRespGPBDef is created earlier
client.subscribe('mytopic', function(body, headers) {
  utils.printObj(`CONSUMER << RXD AMQ header and body`);
  utils.printObj(`AMQ body\n [${body.length}] elements`, body);
  let binArray = utils.stringToBinArray(body);
  utils.printObj(`As binArray`,binArray);
  try { 
    let gpbMsg = TestRespGPBDef.decode(binArray);
    utils.printObj('',gpbMsg);
  } catch (decodeExc) {
    console.log(`Could not decode msg`,{decodeExc});
  }
});


When the consumer receives the body from AMQ and tries to decode it,   this 
is the exception:

CONSUMER << RXD AMQ header and body
AMQ body:
[26] elements (typeof [string]): 
['\u0012\u0002hi\u001a\u0005there�\u0006\f\n\nmonkeybutt']
As binArray (typeof [object]): [[
  18,  2,   104,
  105, 26,  5,
  116, 104, 101,
  114, 101, 65533,
  6,   12,  10,
  10,  109, 111,
  110, 107, 101,
  121, 98,  117,
  116, 116, [length]: 26
]]
Could not decode msg {
  decodeExc: Error: invalid wire type 7 at offset 18
      at Reader.skipType 
(/mytest/node_modules/protobufjs/src/reader.js:377:19)
      at Type.TestResponse$decode [as decode] (eval at Codegen 
(/mytest/node_modules/@protobufjs/codegen/index.js:50:33), <anonymous>:20:5)
      at 
/Users/rcox/gitprojects/POSTAPOCALYPSE/speb-hmi/deviceModules/keplerAdapter/test/utils/amqprototest.js:37:39
      at 
/Users/rcox/gitprojects/POSTAPOCALYPSE/speb-hmi/deviceModules/keplerAdapter/node_modules/stomp-client/lib/client.js:206:9
      at Array.map (<anonymous>)
      at StompFrameEmitter.<anonymous> 
(/mytest/node_modules/stomp-client/lib/client.js:205:28)
      at StompFrameEmitter.emit (events.js:210:5)
      at StompFrameEmitter.parseBody 
(/mytest/node_modules/stomp-client/lib/parser.js:136:12)
      at StompFrameEmitter.handleData 
(/mytest/node_modules/stomp-client/lib/parser.js:42:12)
      at Socket.<anonymous> 
(/mytest/node_modules/stomp-client/lib/client.js:188:18)
}

When the "header" index is  set to 1, and the experiment is repeated, the 
decoding does not throw the exception.
On Friday, January 8, 2021 at 12:52:16 AM UTC-7 marc.g...@gmail.com wrote:

> 100 isn't "non-standard" as such, and shouldn't cause anything to fail. 
> What exactly are you seeing?
>
> The valid range is 1-536870911, omitting 19000-19999 (and any reserved 
> areas in your specific messages) smaller numbers are cheaper (fewer bytes) 
> to encode, so are usually preferred - but: that's it.
>
> I'm guessing you're actually using some non-compliant code that is 
> assuming field-headers are single bytes? That is true for very low field 
> numbers (4 bytes, so: 1-15), but field 100 will take two bytes for the 
> header. Is that the problem here?
>
> On Thu, 7 Jan 2021, 22:00 peo stri tise safe, <peostri...@gmail.com> 
> wrote:
>
>> What is the purpose of setting starting index values for a GPB message 
>> definition to something other than 1?  I am seeing a value of 100 in a 
>> particular application and it is causing the encoding of the message to 
>> fail.  Just wondered why the use of values other than 1 for the first item 
>> in the message. 
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Protocol Buffers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to protobuf+u...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/protobuf/957aae3b-32f8-4d9d-8f5f-732e26e08cedn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/protobuf/957aae3b-32f8-4d9d-8f5f-732e26e08cedn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/protobuf/d5992014-610f-455c-ab5e-b1c5645dc1aen%40googlegroups.com.

Reply via email to