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.

Sign up for GitHub

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

Jump to bottom

In Protobuf messages the "option csharp_namespace ..." attribute is ignored #229

Open
jplumhoff opened this issue Sep 20, 2021 · 2 comments · May be fixed by #560
Open

In Protobuf messages the "option csharp_namespace ..." attribute is ignored #229

jplumhoff opened this issue Sep 20, 2021 · 2 comments · May be fixed by #560
Labels
bug Something isn't working

Comments

@jplumhoff
Copy link

In our protobuf messages, we specify both the package and the csharp namespace. For example:

syntax = "proto3";

package iss.protobuf.digital_production;

import "google/protobuf/wrappers.proto";

option csharp_namespace = "Iss.Protobuf.DigitalProduction";

message DocumentDataSetInsertReply {
  enum Statuses {
    DOCUMENTDATAINSERT_STATUS_UNSPECIFIED = 0;
    DOCUMENTDATAINSERT_STATUS_COMPLETE = 1;
    DOCUMENTDATAINSERT_STATUS_FAILED = 2;
  }
  Statuses status = 1;
  google.protobuf.StringValue message = 2;
}

These messages do not deserialize correctly. The ConfluentProtobufTypeNameResolver returns "iss.protobuf.digital_production.DocumentDataInsertReply" instead of the expected "Iss.Protobuf.DigitalProduction.DocumentDataInsertReply".

I had hoped that I could pull the csharp_namespace from the FileDescriptorProto returned by the message parser. But when autoregistering the schema with the registry, it looks like the csharp_namespace attribute is filtered out of the stored schema.
@dougolima dougolima added the bug Something isn't working label Sep 30, 2021
@JoaoRodriguesGithub
Copy link
Contributor

Hi @dougolima ,

Thank you for your contribution.

We are sorry to provide feedback just now.

Can you please consider update to the latest KafkaFlow version and check if the issue still persist?

We see this action valuable to pursue this topic in the near future.

@esskar esskar linked a pull request Apr 17, 2024 that will close this issue
Open
4 tasks
@ededddy
Copy link

ededddy commented Nov 10, 2024

Hi, I see that there is a PR on going here. Just here to give a small update.

I tried to run a small sample with Confluent schema registry and some protobuf types.

Confirmed that the handlers are never invoked when the protobuf definition package and option csharp_namespace is different (e.g. package xxx.yyy and option csharp_namespace = "xxx.zzz.yyy";)

While I am at it, I also defined 2 variations and tested them.

  1. No options csharp_namespace defined. Consume successfully and break point can be triggered.
syntax = "proto3";
package SchemaRegistry;

message KafkaFlowMessage {
    string Message = 1;
    int32 Code = 2;
}
  1. Defined option csharp_namespace same as package. Break point can be normally triggered.
syntax = "proto3";
package SchemaRegistry;

option csharp_namespace="SchemaRegistry";

message KafkaFlowMessage {
    string Message = 1;
    int32 Code = 2;
}
  1. Defined option csharp_namespace and package but namespace is misspelled. Break point can not be triggered and the offsets are commited right away.
syntax = "proto3";
package SchmeaRegistry;

option csharp_namespace="SchemaRegistry";

message KafkaFlowMessage {
    string Message = 1;
    int32 Code = 2;
}

All of the above cases are tested in version 3.0.10.
Moreover, for case 3, WhenNoHandlerFound delegate is not triggered. I believe thats related to #284 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: add support for csharp namespace in protobuf schemas esskar/kafkaflow
4 participants
@dougolima @jplumhoff @ededddy @JoaoRodriguesGithub