haberman / protobuf

Protocol Buffers - Google's data interchange format

Home Page:https://developers.google.com/protocol-buffers/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

mergeFromJsonString fails with `Error occurred during parsing` error

PierrickVoulet opened this issue · comments

What version of protobuf and what language are you using?
Version: php-upb-msg (protobuf2)
Language: PHP

What operating system (Linux, Windows, ...) and version?
Linux 5.2.17-1rodete3-amd64 x86_64

What runtime / compiler are you using (e.g., python version or gcc version)
PHP Extension (C implementation)

What did you do?
Loaded this json content into a TestSuite message instance at runtime using the following script:

<?php
$testSuite = new TestSuite();
$testSuite->mergeFromJsonString($filepath);
print $testSuite->getTestCases()->count() . PHP_EOL;

What did you expect to see

9

What did you see instead?
PHP Fatal error: Uncaught Exception: Error occurred during parsing: Expected string

Anything else we should know about your project / environment
None.

I tracked this down to the following fragment:

"expected_mask": {}

Here expected_mask is a FieldMask. The new parser expects this to be a string. I guess the old parser was lenient and accepted an empty object here.

What generated this payload? Can it be fixed to serialize an empty FieldMask as ""? Or do we need to change the new parser to accept this? (ideally behind some compatibility flag that we can eventually remove).

btw. I need to add line/col info to the error output so this is easier to diagnose!

I tracked this down to the following fragment:

"expected_mask": {}

Here expected_mask is a FieldMask. The new parser expects this to be a string. I guess the old parser was lenient and accepted an empty object here.

What generated this payload? Can it be fixed to serialize an empty FieldMask as ""? Or do we need to change the new parser to accept this? (ideally behind some compatibility flag that we can eventually remove).

Good catch. I tried with empty string but it now fails because of the snake case being used for field names throughout the file content. This seems to be an issue on our side, I will continue digging this.

Verified