Skip to content
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

[BUG] Properties with default values are not shown in Response pane. #45

Closed
DaveNay opened this issue Jan 18, 2023 · 4 comments
Closed
Labels
bug Something isn't working good first issue Good for newcomers
Milestone

Comments

@DaveNay
Copy link

DaveNay commented Jan 18, 2023

Describe the bug
Due to the deprecation of BloomRPC, we are searching for an alternative solution. When comparing the Response shown in BloomRPC vs the response shown in ezy we discovered that properties that have default values (for their respective data type) are not shown in ezy.

To Reproduce
Steps to reproduce the behavior:

  1. Invoke a gRPC call where the response contains properties with default values.

Expected behavior
Default values should be shown in the ezy Response pane.

Screenshots
image

The BloomRPC response is shown at the top, ezy response below. Properties with default values are highlighted in yellow.

Environment

  • OS: Windows 10 Enterprise 21H2
  • ezy Version [1.0.0-beta.15]

Additional context
N/A

@DaveNay DaveNay added the bug Something isn't working label Jan 18, 2023
@notmedia notmedia added this to the v1-beta.16 milestone Jan 18, 2023
@notmedia notmedia added the good first issue Good for newcomers label Jan 18, 2023
@notmedia
Copy link
Contributor

Hi @DaveNay! Thank you for opening this issue.

I will add default values in response in next release and ping you. I need to check that library that I'm using supports this, if yes I will add this fast.

Also I see on screenshot that response timings are not human readable in ezy, will fix this too.

@notmedia
Copy link
Contributor

@DaveNay I have one question, you said:

Invoke a gRPC call where the response contains properties with default values.

Which protobuf version are you using?

In protobuf 2 we can set custom default values.

According to protobuf 3 specs they are saying that you can't define default values. If your server didn't sent the field, gRPC automatically sets the default value by this convention:

For strings, the default value is the empty string.
For bytes, the default value is empty bytes.
For bools, the default value is false.
For numeric types, the default value is zero.
For [enums](https://protobuf.dev/programming-guides/proto3/#enum), the default value is the first defined enum value, which must be 0.
For message fields, the field is not set. Its exact value is language-dependent. See the [generated code guide](https://protobuf.dev/reference/) for details.

Also if the field is optional:

optional field is in one of two possible states:
the field is set, and contains a value that was explicitly set or parsed from the wire. It will be serialized to the wire.
the field is unset, and will return the default value. It will not be serialized to the wire.

I think I will cover both versions, but need to understand users needs, thanks!

@DaveNay
Copy link
Author

DaveNay commented Jan 20, 2023

@notmedia Thanks for looking into this. We are using protobuf 3. It's not that we are defining default values, I'm only referring to the default values for POCO types:

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/default-values

@notmedia notmedia modified the milestones: v1-beta.16, v1-beta.17 Jan 23, 2023
@notmedia
Copy link
Contributor

@DaveNay Released, please give a try and message me if something goes wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers
Projects
Status: Done
Development

No branches or pull requests

2 participants