fix(streaming): identify the SDK on the WebSocket handshake - #95
Merged
karlwaldman merged 1 commit intoAug 23, 2026
Merged
Conversation
Copy link
Copy Markdown
Member
Sorry, something went wrong.
The ActionCable upgrade request is an ordinary HTTP request, but the streaming client sent only `Authorization` on it. A streaming connection was therefore indistinguishable from a hand-rolled WebSocket and dropped out of SDK attribution entirely, while the HTTP path has always been attributed correctly. The Go SDK already sets a User-Agent on its handshake (stream.go); this brings Python into line and adds the X-SDK-* pair the HTTP path sends. Also pins the server-side attribution contract from the SDK side. The server parses sdk_language/sdk_version out of the User-Agent with `/oilpriceapi-([a-z0-9-]+)\/v?([\d]+\.[\d]+\.?[\d]*)/i` (MinimalAnalyticsService#detect_sdk_info). A UA that stops matching it still returns 200 — the request succeeds and the SDK silently vanishes from adoption reporting. Nothing on either side guarded that shape, so the new tests assert the parsed language and version, not just a substring, across the sync, async and streaming paths. Proven red-capable: changing SDK_NAME to `oilpriceapi_python` fails all four; the streaming test failed before the fix (headers were ['authorization']) and passes after. Verified: 539 passed, 13 skipped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JKAExynd9zoKwt6rYA66EA
Copy link
Copy Markdown
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 9a57fc9c-8ec3-458a-826f-77a947270986 Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. ❤️ ShareComment @coderabbitai help to get the list of available commands. |
Sorry, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this is not
This started as "make sdk_version populate" (it sits at 1.65% of requests). That premise is refuted. I verified in production that every SDK which sends a User-Agent is already parsed correctly — oilpriceapi-python/1.12.8 python/3.12.14 arrives with sdk_language=python, sdk_version=1.12.8. There is no client-side or server-parsing defect on the HTTP path.
The 1.65% is a denominator artefact plus contamination, not a bug in this repo (the fixes are server-side and are being routed separately). Notably the bucket named sdk-python is 348 requests ours out of 23,417 — the rest is generic python-requests/python-httpx traffic the server files under the same name.
What this actually fixes
One real, verified gap in this repo: the WebSocket handshake sent no SDK identification at all.
oilpriceapi/streaming/client.py sent only Authorization on the ActionCable upgrade. That upgrade is an ordinary HTTP request, so a streaming client was indistinguishable from a hand-rolled WebSocket and dropped out of SDK attribution entirely — while the HTTP path was attributed correctly all along.
The Go SDK already does this properly (stream.go sets User-Agent). Python and Node did not. This brings Python into line.
Honest scope of the benefit
This does not by itself make streaming measurable. ApplicationCable::Connection#track_connection in oilpriceapi-api deliberately does not record user_agent — issue #1291 removed it as fingerprinting data under data minimisation. So this is a prerequisite, not a win: the client now sends what a server could attribute, and whether the server should record it is a separate privacy decision, not something this PR presumes.
I would rather say that plainly than imply a metric will move.
The regression guard is the durable half
The server parses attribution with exactly:
A User-Agent that stops matching it still returns 200. The request succeeds and the SDK silently disappears from adoption reporting — a failure no HTTP-level test would ever catch, and nothing on either side guarded the shape. The new tests assert the parsed language and version, not a substring, across the sync, async and streaming paths.
Red-capability proven
Changing SDK_NAME to oilpriceapi_python fails all four new tests. The streaming test failed before the fix for exactly the right reason — headers were ['authorization'] — and passes after. Reverted before commit.
Note the first draft of the streaming test failed for the wrong reason (a missing cable_url kwarg, then a fake peer that replayed welcome forever and hung _subscribe). Both were fixed so the red state genuinely demonstrates the defect.
Verification
Includes the 13 pre-existing test_streaming.py tests, still green.
Please do not merge yet
Per house rules an SDK release changes what customers run. Leaving this open for review.
🤖 Generated with Claude Code
https://claude.ai/code/session_01JKAExynd9zoKwt6rYA66EA