Skip to content

feat(cli): configurable gRPC max receive message size#3141

Open
lemonprogis wants to merge 1 commit into
chainloop-dev:mainfrom
lemonprogis:grpc-patch
Open

feat(cli): configurable gRPC max receive message size#3141
lemonprogis wants to merge 1 commit into
chainloop-dev:mainfrom
lemonprogis:grpc-patch

Conversation

@lemonprogis
Copy link
Copy Markdown
Contributor

Description

The CLI's gRPC client used gRPC's built-in 4 MiB cap on incoming unary messages, which is below what some control-plane responses (notably workflow run describe with many materials/policies) now produce. Hitting it failed the command with grpc: received message larger than max. Raising max_recv_msg_size on the control plane didn't help because that knob governs server-inbound, not the CLI's receive side.

Changes

  • pkg/grpcconn now applies a bounded DefaultMaxRecvMsgSize of 32 MiB to all client connections, replacing gRPC's 4 MiB default.
  • New grpcconn.WithMaxRecvMsgSize(int) option for explicit overrides.
  • New CLI persistent flag --max-recv-msg-size, config key api-max-recv-msg-size, and env var CHAINLOOP_API_MAX_RECV_MSG_SIZE. 0 keeps the default.
  • Wired through the control-plane and CAS dial sites in cmd/root.go and cmd/artifact.go.
  • Regenerated CLI reference docs.

Server-side max_recv_msg_size (already exposed in control-plane config) and the new client-side flag are now symmetric, documented knobs.

Related to #3048

AI disclosure

Assisted by Claude Code.

…rger workflow runs

Signed-off-by: lemonprogis <edward.briggler@gmail.com>
Copy link
Copy Markdown

@cubic-dev-ai cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 5 files

Re-trigger cubic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant