ConstReadonlyOK: 0ReadonlyCANCELLED: 1ReadonlyUNKNOWN: 2ReadonlyINVALID_ARGUMENT: 3ReadonlyDEADLINE_EXCEEDED: 4ReadonlyNOT_FOUND: 5ReadonlyALREADY_EXISTS: 6ReadonlyPERMISSION_DENIED: 7ReadonlyRESOURCE_EXHAUSTED: 8ReadonlyFAILED_PRECONDITION: 9ReadonlyABORTED: 10ReadonlyOUT_OF_RANGE: 11ReadonlyUNIMPLEMENTED: 12ReadonlyINTERNAL: 13ReadonlyUNAVAILABLE: 14ReadonlyDATA_LOSS: 15ReadonlyUNAUTHENTICATED: 16ReadonlyCONTRACT_VIOLATION: 101The wire payload doesn't match the published contract: e.g. the
JSON dict has fields the receiver's @WireType class doesn't
declare, or vice versa. Distinct from INVALID_ARGUMENT because
the violation is about data SHAPE, not value, and shape
violations can occur at any nesting depth (a top-level
INVALID_ARGUMENT label doesn't apply when the bad field is two
objects deep). The producer owns the contract; consumers must
use the field names defined by the producer's manifest.
Aster RPC status codes and error hierarchy.
Spec reference: S6.5 (status codes).
Codes 0-16 mirror gRPC's google.rpc.Code semantically. Codes 100+ are Aster-native and have no gRPC equivalent. The 17-99 range is reserved as a buffer in case gRPC ever extends its enum.
A common gripe with gRPC's status codes is that there are too few to express the variety of failures real services actually hit. The 100+ space gives Aster room to mint more precise codes over time, signalling clearly that they are intentionally separate from the gRPC vocabulary.