gRPC "INVALID_ARGUMENT" in CI

By Daniel Zoghalchali·Latchkey

gRPC status 3 INVALID_ARGUMENT means the server understood the call but found the arguments invalid regardless of the system's state: a required field was empty, a value was out of range, or the message did not match what the handler expects.

What this error means

A call fails with "3 INVALID_ARGUMENT" and a message describing the bad field, such as "id must not be empty" or "value out of range", returned by the handler's own validation.

Error: 3 INVALID_ARGUMENT: id must be a positive integer
    at Object.callErrorFromStatus (.../call.js)

Common causes

A request field fails server-side validation

The handler validates inputs and rejects an empty, malformed, or out-of-range field with INVALID_ARGUMENT.

A field-name or type mismatch in the message

The client populates the wrong field or a mismatched type, so the server reads defaults and treats the request as invalid.

How to fix it

Send fields that satisfy the contract

1. Read the message in the INVALID_ARGUMENT status to see which field is wrong.
2. Populate required fields with valid values matching the proto types.
3. Regenerate stubs if a field name or type drifted from the proto.

client.getUser({ id: 42 }, (err, res) => { /* id must be > 0 */ });

Reproduce the call with grpcurl

Send a known-good payload directly to isolate whether the client message or the data is at fault.

grpcurl -plaintext -d '{"id": 42}' \
  localhost:50051 users.v1.UserService/GetUser

How to prevent it

• Build request messages from generated types so field names and types are checked.
• Mirror the server's validation rules in client-side tests.
• Regenerate stubs whenever the proto changes.

Frequently asked questions

Related guides

References

• GitHub Actions documentation