Skip to content

fix(wasm): resolve stale route_name in wasm context after reroute#3576

Open
Jing-ze wants to merge 2 commits intoalibaba:mainfrom
Jing-ze:fix-envoy-1.36-wasm
Open

fix(wasm): resolve stale route_name in wasm context after reroute#3576
Jing-ze wants to merge 2 commits intoalibaba:mainfrom
Jing-ze:fix-envoy-1.36-wasm

Conversation

@Jing-ze
Copy link
Collaborator

@Jing-ze Jing-ze commented Mar 9, 2026

Ⅰ. Describe what this PR did

After upgrading Envoy from 1.27 to 1.36 (Higress 2.2.0), the ROUTE_NAME property resolution in the wasm context returns stale route names after clearRouteCache() is triggered by a preceding plugin (e.g., transformer with reroute). This causes subsequent plugins' matchRule evaluation to fail, as they see the old route name instead of the re-evaluated one.

Root Cause: In Envoy 1.36, StreamInfoImpl::getRouteName() delegates to route_->routeName(), but clearRouteCache() only clears cached_route_ in ActiveStream — it does NOT update streamInfo().route_. The original code checked info->getRouteName() first (which reads the stale streamInfo().route_), so the second path via filter_callbacks->route() (which correctly triggers route re-evaluation) was never reached.

Fix: Swapped the resolution order in the ROUTE_NAME case of findValue() in context.cc:

  1. Check filter_callbacks->route() first — this triggers refreshCachedRoute() when the route cache has been cleared, returning the correctly re-evaluated route.
  2. Fall back to info->getRouteName() only when filter_callbacks is unavailable (e.g., during access log phase).

Changes:

  • Updated envoy/envoy submodule to include the fix commit (43287ff203)
  • Added e2e test case WasmPluginsRerouteMatchRule to reproduce and verify the fix

Ⅱ. Does this pull request fix one issue?

fixes #3571

Ⅲ. Why don't you add test cases (unit test/integration test)?

An e2e conformance test has been added (go-wasm-reroute-match-rule). It sets up:

  • A transformer plugin (priority 400) with matchRule on a default ingress, mapping query param userId to header x-user-id (triggering reroute)
  • A custom-response plugin (priority 200) with matchRule on a target ingress (matched by x-user-id: 1 header)
  • Verifies that after reroute, the custom-response plugin correctly activates on the new route

Ⅳ. Describe how to verify it

run the e2e test:

make higress-wasmplugin-test PLUGIN_TYPE=GO TEST_SHORTNAME=WasmPluginsRerouteMatchRule

- Add Go test for verifying wasm plugin matchRules work correctly after reroute
- Include two ingress definitions simulating reroute scenario with header-based routing
- Add transformer plugin to map query param to header triggering reroute
- Add custom-response plugin to verify new route is matched and response returned
- Cover issue alibaba#3571 to ensure fresh route name is used after route cache clear
- Add corresponding yaml manifests for ingress and wasm plugin configurations
@codecov-commenter
Copy link

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@Jing-ze
Copy link
Collaborator Author

Jing-ze commented Mar 10, 2026

Need to update the envoy binary.

@CH3CHO
Copy link
Collaborator

CH3CHO commented Mar 10, 2026

--- FAIL: TestHigressConformanceTests/WasmPluginsRerouteMatchRule (300.03s)

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Wasm match_rule doesn't work after reroute triggered in a previous plugin in 2.2.0

3 participants