The listing API does not return a price for a service when it's set to zero.

[rmisio]

If you save a service with a price of 0, a subsequent fetch of the listing does not include the price field at all.

Expectation: If the price was successfully saved as zero, it is returned as 0.

[cpacia]

I don't think this is possible as protobuf omits defaults. And zero is a default. Unless I can some how change the default.

[rmisio]

hmm... there's got to be a way. This is really weird that the client has to say, if the price is omitted, assume it's zero. What if there was a legitimate (very common) use case for there being a difference between a value not being set and set to its default value?

@tyler-smith Tell me PB is not giving us this crap-on-a-stick scenario...?

[cpacia]

looks like explicit default values were removed in proto3

[rmisio]

@cpacia why is zero the default? A required field doesn't need a default right?

[rmisio]

Yeah, this new aspect of PB3 where you cannot distinguish between an unset field vs. a field set to a default value is pretty crappy:

protocolbuffers/protobuf#359

That issue does say there is a work around:

Nullable/optional fields can still be built by wrapping the primitives in submessages. There are predefined types for this in src/google/protobuf/wrappers.proto.

For this specific case, it's not such a huge deal because this is a required field, so we could assume that if we get a service from the server without a price, it must have been set by the user to zero.

But... I imagine there could very well be a scenario were we have an optional field and the client does need to know whether it was never set or had been set to the default. It would be good to have a strategy in place to work around that.

[jjeffryes]

@cpacia and @rmisio did we fix this?