[nu-demo] hero_livekit_ui layer ordering: Extension added inside whitelist middleware #126

Closed
opened 2026-04-23 23:13:57 +00:00 by mik-tf · 1 comment
Owner

Symptom

Every request to /hero_livekit/ui/* returned HTTP 500 with error Missing request extension: WhitelistState. The livekit admin UI was unreachable.

Root cause

hero_livekit/crates/hero_livekit_ui/src/main.rs had layers applied in this order:

.layer(middleware::from_fn(base_path_middleware))
.layer(Extension(whitelist.clone()))
.layer(middleware::from_fn(whitelist::whitelist_middleware))

Axum applies layers outermost-first on incoming requests. Because whitelist_middleware was added AFTER Extension(whitelist) (i.e. it ends up outer), it ran first and tried to read the extension before it was inserted.

Demo workaround (applied 2026-04-23)

Swapped the layer order in hero_livekit_ui/src/main.rs so Extension(whitelist) is the outermost layer (added last), ensuring it is inserted into the request before whitelist_middleware runs. Rebuilt hero_livekit_ui and restarted.

Proper fix

Adopt the fix upstream and add an integration test that hits / on hero_livekit_ui and asserts HTTP 200 (not 500). That test would have caught this silently-regressing ordering bug immediately.

Filed 2026-04-23 nu-shell demo bring-up. Signed-off-by: mik-tf

## Symptom Every request to `/hero_livekit/ui/*` returned HTTP 500 with error `Missing request extension: WhitelistState`. The livekit admin UI was unreachable. ## Root cause `hero_livekit/crates/hero_livekit_ui/src/main.rs` had layers applied in this order: ``` .layer(middleware::from_fn(base_path_middleware)) .layer(Extension(whitelist.clone())) .layer(middleware::from_fn(whitelist::whitelist_middleware)) ``` Axum applies layers outermost-first on incoming requests. Because `whitelist_middleware` was added AFTER `Extension(whitelist)` (i.e. it ends up outer), it ran first and tried to read the extension before it was inserted. ## Demo workaround (applied 2026-04-23) Swapped the layer order in `hero_livekit_ui/src/main.rs` so `Extension(whitelist)` is the outermost layer (added last), ensuring it is inserted into the request before `whitelist_middleware` runs. Rebuilt hero_livekit_ui and restarted. ## Proper fix Adopt the fix upstream and add an integration test that hits `/` on hero_livekit_ui and asserts HTTP 200 (not 500). That test would have caught this silently-regressing ordering bug immediately. Filed 2026-04-23 nu-shell demo bring-up. Signed-off-by: mik-tf
Author
Owner

Fixed in hero_livekit crates/hero_livekit_ui/src/main.rs — the broken layer ordering is gone because the whitelist mechanism was refactored away entirely.

Verification (current hero_livekit_ui/src/main.rs):

  • L18: Extension, Json, Router import — only Extension used now is for BasePath (L174, L214), not WhitelistState.
  • L125: .layer(middleware::from_fn(base_path_middleware)) is the only layer.
  • No Extension(whitelist) insertion, no whitelist_middleware, no WhitelistState references anywhere.

The original symptom (Missing request extension: WhitelistState HTTP 500) cannot recur because neither the Extension nor the middleware exist in the current source.

The issue body's secondary ask — "add an integration test that hits / on hero_livekit_ui and asserts HTTP 200" — would still be a worthwhile follow-up but is regression-test territory, not a blocker for this fix.

Signed-off-by: mik-tf

Fixed in hero_livekit `crates/hero_livekit_ui/src/main.rs` — the broken layer ordering is gone because the whitelist mechanism was refactored away entirely. Verification (current `hero_livekit_ui/src/main.rs`): - L18: `Extension, Json, Router` import — only `Extension` used now is for `BasePath` (L174, L214), not `WhitelistState`. - L125: `.layer(middleware::from_fn(base_path_middleware))` is the only layer. - No `Extension(whitelist)` insertion, no `whitelist_middleware`, no `WhitelistState` references anywhere. The original symptom (`Missing request extension: WhitelistState` HTTP 500) cannot recur because neither the Extension nor the middleware exist in the current source. The issue body's secondary ask — _"add an integration test that hits `/` on hero_livekit_ui and asserts HTTP 200"_ — would still be a worthwhile follow-up but is regression-test territory, not a blocker for this fix. Signed-off-by: mik-tf
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/home#126
No description provided.