CaseClauseError when multiple services are registered in reflection server (Elixir gRPC slack channel)

[sleipnir]

Hello folks,
I’m one of the maintainers of the Elixir gRPC library and I’m forwarding an issue that was reported yesterday in the Elixir gRPC Slack channel. A user ran into a crash when enabling reflection with more than one service.

Below are the details.

Problem Description

Reflection works correctly when only a simple service (e.g., a health check) is registered.
However, when additional services are added to the reflection server, the server crashes with a CaseClauseError.

User-provided log:

2025-11-17T17:18:36.649 [info] Handled by Lore.ReflectionServer.V1.server_reflection_info
2025-11-17T17:18:36.649 [info] Received v1 reflection request: {:file_containing_symbol, "lore"}
2025-11-17T17:18:36.651 [error] ** (CaseClauseError) no case clause matching: {:error, {:function_clause, [{GrpcReflection.Service.Builder.Util, :types_from_descriptor,

The project generates descriptors and code through a Mix alias:

mix protobuf.generate \
  --include-path=priv/protos \
  --plugin=ProtobufGenerate.Plugins.GRPCWithoptions \
  --output-path=./lib \
  --generate-descriptors \
  priv/protos/messages.proto \
  priv/protos/services.proto \
  priv/protos/healthcheck.proto

The service definitions and message types are in separate .proto files.

The user also attempted generating them all in the same file as a test, but the problem persisted.

Questions

To help us narrow this down:

1. Are there any known limitations around multiple-service reflection in the current implementation?
2. Is there a specific expected structure for descriptors that the Elixir generator might not be producing?
3. Are there examples of multi-service reflection setups that could serve as reference?
4. Could this be related to descriptor ordering or file grouping?

Thanks in advance!

[mjheilmann]

Hello @sleipnir

1. There aren't any known limitations around running multiple service reflection, you can see our integration test setups, such as used here
2. Not as far as I know
3. See number 1, those services should be usable for a simple example.
4. Not likely. We do have an issue in file generation, but it's a special case around recursive messages related to proto source traceability ask elixir-protobuf/protobuf#419. This is because we cannot reliably tell what the original real files are, and instead assume each message is its own file. The circular dependency recursion pattern is supported in GRPC, but only if the messages are in the same file. This is not the problem that this user is hitting though.

The user is facing a case clause error, they are providing a type that isn't matched in the function heads. types_from_descriptor is a pattern matching function without a fallback, which is likely what they hit. I left it this way in the hope that it would force discovery about the other types, but adding a fallback to that function would probably correct the issue.

I have the next version WIP updating the grpc dependency, so I can include that. I was trying to include a pic for the circular recursion problem but I can release that and this fix faster if needed. Is this a high priority for the user? LMK

[sleipnir]

I have the next version WIP updating the grpc dependency, so I can include that. I was trying to include a pic for the circular recursion problem but I can release that and this fix faster if needed. Is this a high priority for the user? LMK

I think he can wait, but I'll ask him. Anyway, thank you very much for the reply, and if you need help with the new version of gRPC, let me know.

[mjheilmann]

Fall-through case addressing the case clause error is added in #64

Callout and logic update to reveal and block reflection data loss from conflicts in symbol names or generated file names in #65

These are both included in v0.3.0 published this morning.

[sleipnir]

@mjheilmann Thank you very much for your support and promptness.