Skip to content

Conversation

@ANAMASGARD
Copy link

The CapNProto server was starting unconditionally even when using the default Protobuf protocol. This caused port conflicts when running multiple receiver instances locally and wasted resources.

Fixes #8093

  • I added CHANGELOG entry for this change.
  • Change is not relevant to the end user.

Changes

  • Wrap CapNProto server startup in conditional check for --receive.replication-protocol=capnproto
  • Server now only starts when explicitly configured to use CapNProto
  • Add info log when CapNProto server is disabled (default behavior)
  • Add info log when CapNProto server is starting (when enabled)

Verification

  • make build passes
  • go vet ./cmd/thanos/... passes
  • make format passes

The CapNProto server was starting unconditionally even when using the
default Protobuf protocol. This caused port conflicts when running
multiple receiver instances locally and wasted resources.

Changes:
- Check --receive.replication-protocol flag before starting CapNProto server
- Only start when explicitly set to 'capnproto'
- Add informative log messages for both enabled and disabled states

Fixes thanos-io#8093

Signed-off-by: Gaurav Chaudhary <[email protected]>
Signed-off-by: Gauarv Chaudhary <[email protected]>
Copy link
Contributor

@fpetkovski fpetkovski left a comment

Choose a reason for hiding this comment

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

I can see how starting the capnproto server can be a problem, but this flag is really intended for the router, not the receiver. So if we now merge this PR, existing deployments could break since we are changing default behavior.

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CapNProto gets initialised even though I'm using protobuf

2 participants