Hi Eric, Thank you for your prompt response and clarification. Based on your explanation, I believe we should revise our framework requirements to avoid relying on behavior that may be inconsistent in terms of specifications.
Thank you very much, lcy Eric Anderson 在 2025年2月24日 星期一上午10:50:28 [UTC+8] 的信中寫道： > There's no requirement that implementations support non-standard status > codes. Implementations must handle non-standard status codes, as a new code > could technically be added (even if that would probably cause more problems > than it would solve). But they can either propagate it as-is or convert it > to UNKNOWN. That's currently defined in the status codes definition > <https://github.com/grpc/grpc/blob/master/doc/statuscodes.md>. >> >> Applications should only use values defined above. gRPC libraries that >> encounter values outside this range must either propagate them directly or >> convert them to UNKNOWN. > > > Different implementations can work differently simply because of how those > languages and APIs work. For example, grpc-java uses a Java enum for the > status codes, so it is not feasible to propagate arbitrary integer status > codes in its API. But Go's "enums" allow other integers so it can be > preserved. > > Applications can't define their own status codes, as there is no > application-defined range for such things. So you making your own is > invalid in all languages, but happens to function in some (and could break > if those integers are ever used by grpc itself in the future). > > On Sun, Feb 23, 2025 at 6:40 PM 林建佑 <u90...@gmail.com> wrote: > >> Hi Experts, >> >> We are working in an internal framework that defines certain error codes >> which must be transmitted via gRPC status codes. Initially, since the >> services were implemented in Go, this requirement seemed fine. However, we >> later discovered that the Python library's server implementation cannot >> return non-standard gRPC status codes. >> >> According to a comment in the grpc repository, the Python implementation >> intentionally doesn't support returning non-standard gRPC status codes ( >> https://github.com/grpc/grpc/issues/13321#issuecomment-343238554), >> whereas Go's implementation has no such restriction. I am not familiar with >> the gRPC implementations in other languages, so I am unsure of their >> behavior. >> >> We know we can transmit these messages through error details, but we are >> confused by the substantial differences in behavior between the >> implementations in different languages. Is there any plan to standardize >> this behavior across languages? >> >> Regards, >> lcy >> >> -- >> You received this message because you are subscribed to the Google Groups >> "grpc.io" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to grpc-io+u...@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/grpc-io/ebdee43d-b6e1-4037-b744-346d7b59dbaan%40googlegroups.com >> >> <https://groups.google.com/d/msgid/grpc-io/ebdee43d-b6e1-4037-b744-346d7b59dbaan%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/grpc-io/4c40bf09-61a1-46dc-8643-30c687109c19n%40googlegroups.com.
