fix(vision events): send assume-identity headers on Vision Events API calls - #2774
Conversation
|
👋 Thanks for the pull request! Here is how automated Claude review works here, so you spend credits (and reviewer time) wisely. 🚦 This PR is marked Ready for review, so automated Claude review will run — and every pass spends real credits. Warning 💸 The Claude reviewer bills in credits, not vibesAutomated review spins up a real agent that reads real code and spends real credits on every pass. It is glad to help — but it is not a rubber duck, a linter you poke in a loop, or a substitute for reading the contributing guide. Treat it like an expensive senior reviewer whose time you booked, and show up prepared. Draft when unsure, Ready when you mean it:
However you get there, arrive prepared:
Reviews are not free. A draft costs nothing to review; a Ready PR is a promise that it is worth reviewing.
|
762fc2f to
e38d43e
Compare
6e83f6e to
3e98756
Compare
981d794 to
50133c5
Compare
…t of the app The Vision Events sink built its own request headers, bypassing `build_roboflow_api_headers()`. Every other Roboflow API caller in this repo goes through that builder, which injects the headers configured in `ROBOFLOW_API_EXTRA_HEADERS`. That matters where the API key is not a real credential. A workflow run by an internal service on behalf of a workspace is pointed at a proxy via `API_BASE_URL`, given a placeholder API key, and authenticated entirely by a token in `ROBOFLOW_API_EXTRA_HEADERS`. The sink dropped that token, so its writes were rejected while the block still reported success and the job finished clean - the events were silently lost. Both calls now build their headers with the shared builder. The bearer token is applied with `setdefault`, so where a configured `Authorization` header is the real credential it is not overwritten by one built from a placeholder key. The key is deliberately not moved into the query string: that is how other callers pass it, but it would put the credential into proxy, gateway, and access logs, which no amount of after-the-fact redaction in this block can reach. Both requests now raise through `api_key_safe_raise_for_status`, matching the other callers. The local event store path is untouched - it does not talk to the Roboflow API. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
🤖 Claude review started at commit New commits are not auto-reviewed. Add the |
50133c5 to
735402c
Compare
|
😎 PR passes the vibe-check and trust-me-bro verification. |
Problem
The Vision Events sink (
roboflow_core/roboflow_vision_events@v1) built its own request headers, bypassingbuild_roboflow_api_headers(). Every other Roboflow API caller in this repo goes through that builder, which injects whatever headers are configured inROBOFLOW_API_EXTRA_HEADERS.That matters wherever the API key is not itself a real credential. A workflow run by an internal service on behalf of a workspace is pointed at a proxy through
API_BASE_URL, handed a placeholder API key, and authenticated entirely by a token supplied inROBOFLOW_API_EXTRA_HEADERS. The sink dropped that token, so its writes were rejected upstream — while the block still reported success and the run finished clean. The events were silently lost.Change
inference/core/workflows/core_steps/sinks/roboflow/vision_events/v1.py:POST /vision-events/uploadandPOST /vision-events) now build their headers withbuild_roboflow_api_headers().Content-Typeis passed throughexplicit_headersrather than merged in afterwards, so a deployment's configured headers cannot be clobbered.setdefault. Where a configuredAuthorizationheader is the real credential and the API key is a placeholder, the configured value wins.api_key_safe_raise_for_status, matching the other callers.The API key stays out of the request URL. Passing it as an
api_keyquery parameter is how other callers in this repo send it and the API accepts that form, but a query string is recorded by proxy, gateway, and access logs before any redaction in this block could apply. A header keeps it out of that path, and nothing about this fix depends on the transport — where the placeholder key is in play, neither form is read.The local event store path (
write_to_event_store: true) is untouched. It does not talk to the Roboflow API.Notes
This is one half of the fix, and the other half has shipped: the API now accepts that token on the Vision Events ingest routes. With both in place these writes land instead of being rejected.
Tests
New coverage:
Content-Typereaches it as an explicit header rather than being appended after.Authorizationheader is not overwritten by the bearer token built from the API key.