Skip to content

[.NET] Identify the SDK in the User-Agent header - #653

Open
ivanvyd wants to merge 1 commit into
databricks:mainfrom
ivanvyd:fix/dotnet-sdk-identifier
Open

[.NET] Identify the SDK in the User-Agent header#653
ivanvyd wants to merge 1 commit into
databricks:mainfrom
ivanvyd:fix/dotnet-sdk-identifier

Conversation

@ivanvyd

@ivanvyd ivanvyd commented Jul 31, 2026

Copy link
Copy Markdown

What changes are proposed in this pull request?

.NET clients identify themselves as zerobus-sdk-rs/<version> on the wire. Build() sent the SDK identifier only when the caller set one, and SdkIdentifier() is documented for wrapper SDKs rather than end-user code, so it stays unset and the core falls back to its own default.

Server-side, that attributes .NET traffic to Rust: .NET adoption is unmeasurable, and logs for a .NET customer name the wrong SDK. Go and C++ already stamp theirs unconditionally.

Before:

zerobus-sdk-rs/2.6.0 tonic/0.14.5

After:

zerobus-sdk-dotnet/0.1.0 tonic/0.14.5

How is this tested?

Four integration tests on the existing mock gRPC server, asserting the user-agent header the server received. dotnet test: 210 passed, 0 failed, across net8.0 and net10.0.

End to end, I ran a pre-fix and a post-fix build against a live Zerobus endpoint on Azure Databricks; both ingested successfully.

The identifier was sent only when the caller supplied one, so a default-configured
client reported the Rust core's own identifier and .NET traffic was attributed to
Rust server-side. Go and C++ both stamp theirs unconditionally.

Captured against the mock server: zerobus-sdk-rs/2.6.0 before, zerobus-sdk-dotnet/0.1.0
after. An explicit SdkIdentifier() still takes precedence.

Signed-off-by: Ivan Vydrin <ivan.vydrin.99@gmail.com>
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