Stephen Haberman

> Optionals are not deserialized into default values. I mean, I agree intuitively, that's just not what the proto docs I linked to above assert... I.e. you say "turned into...

...so you're saying that the message would actually contain the optional element, i.e. on the wire somewhere is the data that "`fieldA` is not set"? I.e. `fieldA` is actually in...

This is from the proto2 docs I linked to above: "When a message is parsed, if it does not contain an optional element, the corresponding field in the parsed object...

Lol, well, that explains why we were talking in circles. :-D Fwiw I get why you're are doing it that way, I personally think it makes more sense... But not...

@eyalpost I agree the lack of hazzers is unfortunate; I've historically gone back/forth on "would clients prefer being able to detect not-present" or "would clients prefer not having to 'or'...

Ah yeah, thanks for the report @dustyhorizon ... ...just glancing at it, it looks like `grpc-js` client output is slightly different clients, i.e. other outputs do generate separate `TestClient` (interface)...

@fenos sure, that'd be great to have! I think ts-proto not having it is primarily an artifact of: a) ts-proto is not really an out-of-the-box RPC framework, but instead more...

@hersentino it's a little adhoc, but you could do something like `Object.keys( DashAPICredsClientImpl)` using the class: https://github.com/stephenh/ts-proto/blob/16b4aca98aa9f0266734421314baaa5259e3f4e2/integration/grpc-web/example.ts#L814 If you need something more automatic, there is a `outputTypeRegistry` flag that currently...

Personally I'd be tempted to cheat and assert/nudge the server to return pagination info in-band, instead of as metadata, but otherwise yet-another-option to generate this style of output sounds fine.

@mmahalwy `run.sh` is just a convenience method for "run ts-node with some env defaults and some `-r` defaults", i.e. nothing core/really related to Joist itself, so downstreams projects are free...