[nu-demo] hero_livekit_ui layer ordering: Extension added inside whitelist middleware #126
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Symptom
Every request to
/hero_livekit/ui/*returned HTTP 500 with errorMissing request extension: WhitelistState. The livekit admin UI was unreachable.Root cause
hero_livekit/crates/hero_livekit_ui/src/main.rshad layers applied in this order:Axum applies layers outermost-first on incoming requests. Because
whitelist_middlewarewas added AFTERExtension(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.rssoExtension(whitelist)is the outermost layer (added last), ensuring it is inserted into the request beforewhitelist_middlewareruns. 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
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):Extension, Json, Routerimport — onlyExtensionused now is forBasePath(L174, L214), notWhitelistState..layer(middleware::from_fn(base_path_middleware))is the only layer.Extension(whitelist)insertion, nowhitelist_middleware, noWhitelistStatereferences anywhere.The original symptom (
Missing request extension: WhitelistStateHTTP 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