[Bug] Inconsistent field naming for Message type (request/msg/message) #1230
Description
Bug Description
There's an inconsistency in how Message fields are named across the proto file, due to message being a reserved keyword in Protocol Buffers. It is best practice to not use reserved words for field names.
Current State
The proto file uses different field names for Message objects in different contexts:
1. request - SendMessageRequest (line 679)
message SendMessageRequest {
Message request = 1
[(google.api.field_behavior) = REQUIRED, json_name = "message"];
// ...
}- Field name:
request - JSON name:
message
2. msg - SendMessageResponse & StreamResponse (lines 810, 822)
message SendMessageResponse {
oneof payload {
Task task = 1;
Message msg = 2 [json_name = "message"];
}
}
message StreamResponse {
oneof payload {
Task task = 1;
Message msg = 2 [json_name = "message"];
// ...
}
}- Field name:
msg - JSON name:
message
3. message - TaskStatus (line 182)
message TaskStatus {
// ...
Message message = 2;
// ...
}- Field name:
message(no json_name override needed)
Problem
The inconsistency has the potential to cause confusing.
Proposed Solutions
Option 1
Standardize all Message field names to use message consistently:
// Option 1: Use 'message' everywhere
message SendMessageRequest {
Message message = 1 [(google.api.field_behavior) = REQUIRED];
// ...
}
message SendMessageResponse {
oneof payload {
Task task = 1;
Message message = 2;
}
}
message StreamResponse {
oneof payload {
Task task = 1;
Message message = 2;
// ...
}
}Option 2
// Option 2: If 'message' truly is problematic in some contexts,
// consistently use 'msg' everywhere with json_name override
message SendMessageRequest {
Message msg = 1
[(google.api.field_behavior) = REQUIRED, json_name = "message"];
// ...
}
message TaskStatus {
TaskState state = 1 [(google.api.field_behavior) = REQUIRED];
Message msg = 2 [json_name = "message"];
// ...
}Impact
- Breaking change for gRPC clients (field name changes)
- Non-breaking for JSON/HTTP clients (if json_name is used consistently)
- Improves consistency and reduces confusion
- v1.0 is the right time for such breaking changes
Metadata
Metadata
Assignees
Type
Projects
Status