fix(rpc): UDS transport silently drops X-Hero-Context headers — context isolation broken for direct socket calls #40

New issue

Open

opened 2026-05-07 07:42:06 +00:00 by casper-stevens · 0 comments

casper-stevens commented

2026-05-07 07:42:06 +00:00

Member

Root cause (code-verified, 2026-05-07)

Supersedes earlier AI-generated analysis in #37, lhumina_code/hero_osis#46, and lhumina_code/hero_rpc#42 with verified findings from reading the actual source.

Finding 1 — hero_rpc UDS transport drops X-Hero-Context headers (real bug)

File: hero_rpc/crates/openrpc/src/transport.rs

The post_raw_json_with_headers() method accepts a header slice but silently ignores it for Unix Domain Socket transport. Only HTTP transport passes headers through. The docstring documents this explicitly:

"Unix-socket transport currently drops the headers — raw socket framing has no place to carry them; callers on UDS paths should put context in the body."

This means any service talking to another service directly over UDS while relying on X-Hero-Context for context isolation will silently get the wrong context. Tracked in lhumina_code/hero_rpc#42.

Finding 2 — hero_osis OsisClient endpoint and header construction is already correct

File: hero_rpc/crates/openrpc_http_client_lib/src/lib.rs

OsisClient::new() constructs {base_url}/hero_osis_{domain}/rpc and calls post_raw_json_with_headers with [("X-Hero-Context", &self.context)]. Since this uses HTTP transport (through hero_router), the header is forwarded correctly.

The Cargo.lock in hero_osis pins hero_rpc_client at commit e512c1bf (development branch) — the endpoint format is already correct in the current state.

The cargo update recommendation in lhumina_code/hero_osis#46 and the endpoint format analysis in #37 were based on stale/hallucinated analysis and do not reflect the actual code.

What needs to happen

P1 — Fix UDS header forwarding in hero_rpc

Thread extra_headers through http_post_unix() in transport.rs so that X-Hero-Context and X-Hero-Claims survive the UDS hop. This is required for any service that communicates with another service directly over UDS and needs context isolation.

Tracked in lhumina_code/hero_rpc#42.

Stale analysis to disregard

lhumina_code/hero_osis#46 (cargo update for hero_rpc_client) — current Cargo.lock already has the correct endpoint format
#37 Layer 1 analysis (wrong endpoint format) — OsisClient already uses the correct format

Owner: Casper (lhumina_code/hero_rpc#42 UDS fix)
Source: Code-verified 2026-05-07

## Root cause (code-verified, 2026-05-07) > Supersedes earlier AI-generated analysis in #37, [lhumina_code/hero_osis#46](https://forge.ourworld.tf/lhumina_code/hero_osis/issues/46), and [lhumina_code/hero_rpc#42](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/42) with verified findings from reading the actual source. --- ### Finding 1 — hero_rpc UDS transport drops X-Hero-Context headers (real bug) **File:** `hero_rpc/crates/openrpc/src/transport.rs` The `post_raw_json_with_headers()` method accepts a header slice but silently ignores it for Unix Domain Socket transport. Only HTTP transport passes headers through. The docstring documents this explicitly: > *"Unix-socket transport currently drops the headers — raw socket framing has no place to carry them; callers on UDS paths should put context in the body."* This means any service talking to another service directly over UDS while relying on `X-Hero-Context` for context isolation will silently get the wrong context. Tracked in [lhumina_code/hero_rpc#42](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/42). --- ### Finding 2 — hero_osis OsisClient endpoint and header construction is already correct **File:** `hero_rpc/crates/openrpc_http_client_lib/src/lib.rs` `OsisClient::new()` constructs `{base_url}/hero_osis_{domain}/rpc` and calls `post_raw_json_with_headers` with `[("X-Hero-Context", &self.context)]`. Since this uses **HTTP** transport (through hero_router), the header is forwarded correctly. The Cargo.lock in hero_osis pins `hero_rpc_client` at commit `e512c1bf` (development branch) — the endpoint format is already correct in the current state. The `cargo update` recommendation in [lhumina_code/hero_osis#46](https://forge.ourworld.tf/lhumina_code/hero_osis/issues/46) and the endpoint format analysis in #37 were based on stale/hallucinated analysis and do not reflect the actual code. --- ## What needs to happen ### P1 — Fix UDS header forwarding in hero_rpc Thread `extra_headers` through `http_post_unix()` in `transport.rs` so that `X-Hero-Context` and `X-Hero-Claims` survive the UDS hop. This is required for any service that communicates with another service directly over UDS and needs context isolation. Tracked in [lhumina_code/hero_rpc#42](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/42). --- ## Stale analysis to disregard - **[lhumina_code/hero_osis#46](https://forge.ourworld.tf/lhumina_code/hero_osis/issues/46)** (`cargo update` for hero_rpc_client) — current Cargo.lock already has the correct endpoint format - **#37** Layer 1 analysis (wrong endpoint format) — OsisClient already uses the correct format --- **Owner:** Casper ([lhumina_code/hero_rpc#42](https://forge.ourworld.tf/lhumina_code/hero_rpc/issues/42) UDS fix) **Source:** Code-verified 2026-05-07

casper-stevens changed title from ~~fix(ai): AI assistant hallucinates CRM data — tools not wired to OSIS~~ to fix(rpc): UDS transport silently drops X-Hero-Context headers — context isolation broken for direct socket calls

2026-05-07 07:51:40 +00:00

casper-stevens referenced this issue

2026-05-07 07:56:07 +00:00

bug: context selection has no effect — all contexts return same data #37

casper-stevens added a new dependency

2026-05-08 11:31:18 +00:00

#15 Route AiClient through local AI Broker instead of direct provider calls

casper-stevens removed a dependency

2026-05-08 11:31:23 +00:00

#15 Route AiClient through local AI Broker instead of direct provider calls