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

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

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

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

jplumhoff opened this issue Sep 20, 2021 · 1 comment · 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
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Development

Successfully merging a pull request may close this issue.

3 participants