Skip to content

feat: add X-LaunchDarkly-Instance-Id header (SDK-2351)#258

Open
keelerm84 wants to merge 2 commits into
mainfrom
mk/sdk-2351-instance-id
Open

feat: add X-LaunchDarkly-Instance-Id header (SDK-2351)#258
keelerm84 wants to merge 2 commits into
mainfrom
mk/sdk-2351-instance-id

Conversation

@keelerm84
Copy link
Copy Markdown
Member

@keelerm84 keelerm84 commented May 12, 2026

Summary

Adds the X-LaunchDarkly-Instance-Id header to every outbound polling, streaming, and event request. Value is a v4 UUID generated once per SDK instance (via Guid.NewGuid()) and stable for that instance's lifetime.

The GUID is attached via the immutable HttpProperties builder before the user-custom-header aggregation, matching the User-Agent / Authorization override convention.

Test plan

  • `dotnet test` on net8.0 — Passed 1574 / Failed 0
  • Server SDK build (net462, netstandard2.0, net8.0) — 0 warnings, 0 errors
  • Contract test service jar builds clean with `instance-id` capability registered
  • CI green across all target frameworks (net462 run requires mono, exercised by CI)

Note

Medium Risk
Adds a new default HTTP header on all SDK network requests, which could affect downstream proxies/gateways and request deduping/observability expectations. Logic is straightforward but touches shared request configuration used across polling/streaming/events.

Overview
Adds a new default X-LaunchDarkly-Instance-Id header to SDK HTTP configuration, generated once as a UUIDv4 per HttpConfigurationBuilder instance and applied to the underlying HttpProperties.

Ensures custom headers can override this header (consistent with existing override behavior), adds unit tests covering presence/UUIDv4 format/uniqueness vs. stability, and registers the instance-id capability in the contract test TestService.

Reviewed by Cursor Bugbot for commit ea77df6. Bugbot is set up for automated code reviews on this repo. Configure here.

Generate a v4 UUID once per SDK instance in HttpConfigurationBuilder.Build
and stamp it on the default headers. Because those headers are shared by
the stream, poll, and event clients, every outbound request carries the
same stable per-instance identifier without per-channel plumbing. The
instance id is applied before user-supplied custom headers so custom
headers can override it, matching the convention used for the User-Agent
and Authorization headers (and the other LaunchDarkly SDKs).

Registers the "instance-id" capability with the contract test service so
the cross-SDK harness can verify the header on stream, poll, and event
requests.
@keelerm84 keelerm84 requested a review from a team as a code owner May 12, 2026 20:59
Copy link
Copy Markdown

@cursor cursor Bot left a comment

Choose a reason for hiding this comment

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

Cursor Bugbot has reviewed your changes using default mode and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit 528b9e0. Configure here.

Comment thread pkgs/sdk/server/src/Integrations/HttpConfigurationBuilder.cs Outdated
Generate the X-LaunchDarkly-Instance-Id GUID once at builder construction
instead of regenerating it on each MakeHttpProperties call, so that
Build() and DescribeConfiguration() (both invoked per SDK instance) see
the same value.
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