Skip to content

Ability to ignore parsing proto Any field type. #684

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

Open
brion-fuller opened this issue Mar 27, 2025 · 0 comments
Open

Ability to ignore parsing proto Any field type. #684

brion-fuller opened this issue Mar 27, 2025 · 0 comments

Comments

@brion-fuller
Copy link

What is the underlying problem you're trying to solve?

Today, I have services that act as a delievery pipeline for downstream services. We are looking to parse the outer part of a message. This type is well defined expect for the inner data which is a google.protobuf.Any. We do not wish to parse of act on this data as it's not defined when it comes to our service. We, also, don't have the definitions available ahead of time. This causes an error like "message": "proto: google.protobuf.Any: unable to resolve \"[type.googleapis.com/foo.bar.unknown.type](http://type.googleapis.com/foo.bar.unknown.type)\": not found".
It is happening because of protojson.Marshal(msg) in the request. This is expected behavior for the default use-case of protojson.

Describe the ideal solution

Envoy-opa should try to resolve google.protobuf.Any, If the type is unknown, the request shouldn't fail but continue forward. In the case, when a field is unknown and was unable to parse we could return "@error" field along with the original values something similar to fullstorydev/grpcurl#193 (comment). If we don't care for any types ahead of time, we should be able to ignore the field completely.

Describe a "Good Enough" solution

Add an option that lets users tell envoy-opa to ignore any fields.

Additional Context

You can setup Options for marshalling and redefine the Resolvers that would ignore any type cases.

	// messages. If nil, this defaults to using protoregistry.GlobalTypes.
	Resolver interface {
		protoregistry.ExtensionTypeResolver
		protoregistry.MessageTypeResolver
	}```
@srenatus srenatus transferred this issue from open-policy-agent/opa Mar 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant