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 林建佑 <u900...@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+unsubscr...@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/CA%2B4M1oNF9gYHdkFRJXE4aqQHGLgr3BG6KE7wBob%3DVkW5kv64ew%40mail.gmail.com.
smime.p7s
Description: S/MIME Cryptographic Signature
