New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`decode()` fails silently when passing in a wrong type #695

Closed
tomergg opened this Issue Mar 3, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@tomergg

tomergg commented Mar 3, 2017

protobuf.js version: 6.6.5

When passing in a ByteBuffer instead of a Uint8Array, decode fails silently and return an "empty" message. Calling toObject on the message will return an empty object. The expected is to validate the input parameters and throw an exception if it's of an invalid type.

try {
  const pbNotifications = pbRoot.lookup('Notifications');
  const data = new ByteBuffer(...);
  const notification = pbNotifications.Notification.decode(data).toObject();
} catch (error) {
  logger(error);
}

As a side note. I came across this bug after switching from v5 to v6. A part of the code, where the test coverage was not ideal, was failing silently. It was only discovered at functional QA time.

@dcodeIO

This comment has been minimized.

Owner

dcodeIO commented Mar 4, 2017

I intentionally omitted these assertions for perf reasons because decode is called implicitly for each sub-message, which'd then execute the assertion over and over again. For example, if you have a .proto like ...

message Outer {
   repeated Inner foo = 1;
}
message Inner {
}

... then you'd call Outer.decode(...) yourself, which implicitly calls Inner.decode(...) for each repeated element of foo and so on. Furthermore, the assertion, in this case, would have to check for multiple types: Reader, Buffer under node, Uint8Array in modern respectively Array in older browsers.

Your request is a valid issue, though Ideally, there'd be an unchecked _decode for internal use and a checked decode for the API or something like that (also in static code). and it should be possible to figure something out when moving the check to Reader.create.

@dcodeIO dcodeIO added the enhancement label Mar 4, 2017

@tomergg

This comment has been minimized.

tomergg commented Mar 4, 2017

Thank you again for the quick and detailed answer

Your request is a valid issue, though. Ideally, there'd be an unchecked _decode for internal use and a checked decode for the API or something like that (also in static code).

This sounds like a good solution. The issue is not blocking me in anyway. I quickly fixed my code and it's working well. It was an easy thing to miss moving from v5 to v6, since v5 used ByteBuffer. When this is addressed I think it would make it slightly easier to upgrade.

BTW,
v6.6.5 came just in time. We have a code freeze today.
Thank you again.

dcodeIO added a commit that referenced this issue Mar 4, 2017

dcodeIO added a commit that referenced this issue Mar 4, 2017

@dcodeIO dcodeIO referenced this issue Mar 5, 2017

Closed

Error Handling #696

dcodeIO added a commit that referenced this issue Mar 5, 2017

@dcodeIO

This comment has been minimized.

Owner

dcodeIO commented Mar 22, 2017

Should be fixed in master.

@dcodeIO dcodeIO closed this Mar 22, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment