[grpc] Unable to pass integer value in workflow inputs

Hi we are using the Netflix grpc workflow client (version:com.netflix.conductor:conductor-grpc-client:2.12.1) and we are unable to pass in a integer value in workflow input (or task inputs) during execution.

We are passing in dynamic workflows by using the startWorkflowRequest object.

We see the following error: cannot map to Value type: 40

We suspect this is happening in here: https://github.com/Netflix/conductor/blob/a7a6e32900b7c5cf78b861a144d3e663b9be11c3/grpc/src/main/java/com/netflix/conductor/grpc/ProtoMapper.java#L44

I understand that, these are generated files from protobuf (please correct me if am wrong). Is it possible to update it to support integer values?

Happy to contribute as well, might need some assistance in updating this as I am new to this code base

Thanks in advance!

[vmg]

@sujaysudheenda: No, the file you’ve linked, ProtoMapper.java is not auto-generated. The rest of the protobuf code is, but not that implementation.

It is not possible to add a new method to the Value builder because Value is a standard ProtoBuf type: https://developers.google.com/protocol-buffers/docs/reference/java/com/google/protobuf/Value.Builder – these standard types do not support ProtoBuf INT fields because they need to be mapped 1:1 between ProtoBuf and JSON-ProtoBuf (the JSON specification does not have a concept of “integer”, it only supports “numeric” values which are basically double).

Your best bet here to prevent breaking the ProtoBuf/GRPC spec is adding a type check to toProto that handles Java Integer and casts that to double, calling setNumberValue. You may lose precision here, but again, this is the only way that you’ll be able to support the standard ProtoBuf Value.

Sorry this is inconvenient. I did not design this, Google did. 😄

[vmg]

The interface we designed for GRPC is limited to “numeric” values (i.e. doubles) because of backwards compatibility with the old interface, IIRC. So all numbers need to be floating point. That’s… not ideal. You could simply fix it by updating the toProto method, but I recall this was a breaking change so we did not do it.