Issue with generated Unity API arguments

General
1

Hi folks,

I’ve got two issues with the Unity API codegen.

First, I noticed that the arguments in API calls doesn’t match the order of members specified in the .proto file. Instead, it seems to be alphabetically sorted.

For example, with this proto:

message ChangeStateRequest {
  string namespace = 1;
  string player_id = 2;
  string thing_id = 3;

  uint32 tile = 4;
  int32 state = 5;
  int32 type = 6;
}

The generated API is this:

public IEnumerator ThingserviceChangeState(
    string thingId,
    string playerId,
    int state,
    long tile,
    int type,
    ResultCallback<AccelByteLairCustomlairResponse> callback)
{

This means it can change in unexpected ways.

Second, my repro showed another issue: it looks like uint32 is being converted to long instead of uint in C#. The protobuf spec (v2 and v3) clearly say that uint32 maps to uint on C#. It looks like maybe it’s using the Python rules? long in C# is System.Int64, not System.Uint32, and this kinda messes up the code.

Thanks, Chris

2

Hello @chrislambertus ,

You’ve brought up two key points here:

  1. Maintaining Order: We’ve got an incoming template fix that should address the issue of order between the .proto file and the generated C# file. It’s worth noting that the numbers alongside each field in the .proto file are used for serialization, and their order doesn’t affect how the messages are serialized. Here’s an article that elaborates on this.

  2. Type Conversion: We’re still diving into finding a better workaround for this one. It stems from an issue in the library we’re using to convert RESTful HTTP APIs into gRPC (and vice versa).

    a. :x: proto uint32 → openapi type: integer format: int64 → C# long (instead of C# uint)
    b. :white_check_mark: proto int64 → openapi type: string format: int64 → C# string (instead of C# long)
    c. :white_check_mark: proto uint64 → openapi type: string format: uint64 → C# string (instead of C# ulong)

    While we have an answer to b & c, we’re still looking into a better way to fix the issue you are encountering. Meanwhile, there should be no problems assigning a long value into a supposed uint parameter but you’ll have to clamp the value to avoid integer overflow errors.

    Math.Clamp(value, uint.MinValue, uint.MaxValue)

Cheers!

3

update: we’ve released a new version of the codegen + template (v0.0.14-alpha) that addresses the ordering issue.

4

Thanks, I’ve updated to 0.0.14!

1 Like