grpc-ecosystem/grpc-gateway

Inconsistent enum behaviour

Open

#354 opened on Apr 13, 2017

View on GitHub
 (1 comment) (2 reactions) (0 assignees)Go (16,971 stars) (2,250 forks)batch import
help wanted

Description

Given the following messages and enumeration:

message NameCheckResponse {
    Result result = 1;
}

message MultiNameCheckResponse {
    map<string, Result> results = 1;
}

enum Result {
    AVAILABLE = 0;
    UNAVAILABLE = 1;
    UNKOWN = 2;
}

The returned value in case of the first message is the name of the enum. In the second case, it's the numeric value.

Is this behaviour intended?

Contributor guide

Tech stack
gogrpcrest api
Domain
backendapi
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
needs investigation
Prerequisites
protobuf basicsgRPC concepts
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40
Research direction
Investigate how enum values are marshaled in map fields vs normal fields in the grpc gateway runtime. Look at runtime/marshal json.go and the generated code for map fields. Check if the inconsistency is caused by different serialization paths. Review the protoc gen grpc gateway code generation for map entries. The issue asks whether this behavior is intended, so also check project maintainer comments or related discussions.