[FIX] Preserve response headers across context restore in SecurityInterceptor#6123
Conversation
PR Reviewer Guide 🔍(Review updated until commit 658a214)Here are some key observations to aid the review process:
|
PR Code Suggestions ✨Latest suggestions up to 658a214 Explore these optional code suggestions:
Previous suggestionsSuggestions up to commit 20fe3b8
Suggestions up to commit 20fe3b8
|
|
Persistent review updated to latest commit 20fe3b8 |
…rceptor Signed-off-by: Kishore Kumaar Natarajan <kkumaarn@amazon.com>
20fe3b8 to
658a214
Compare
|
Persistent review updated to latest commit 658a214 |
|
@KishoreKicha14 can you please take a look at the unit test failures? Looks like it might be related to the change in this PR. The change looks sensible to me and I'm surprised it hasn't been brought up before. How exactly does QI use these response headers in a way that other plugins do not? Edit: appears to be due to flakiness |
Description
Use newRestorableContext(true) instead of stashContext() for context restoration in RestoringTransportResponseHandler to preserve response headers (including TASK_RESOURCE_USAGE) across transport round-trips.
Category: Bug fix
Why these changes are required?
When the security plugin is enabled,
SecurityInterceptor.sendRequestDecorate()stashes the ThreadContext via stashContext() before sending transport requests. On response, RestoringTransportResponseHandler.handleResponse() calls StoredContext.restore(), which blindly overwrites the thread-local context — discarding all response headers added during shard-level execution on data nodes. This causes shard-level TASK_RESOURCE_USAGE entries to be silently dropped, so the coordinator only sees its own resource usage.Old behavior: RestoringTransportResponseHandler used ThreadContext.StoredContext from stashContext(), whose restore() discards response headers added after stashing. Shard-level task resource usage data was lost when security plugin was enabled.
New behavior: RestoringTransportResponseHandler uses Supplier<ThreadContext.StoredContext> from newRestorableContext(true), whose get() merges current response headers back into the restored context — matching the pattern used by OpenSearch core's ContextRestoreResponseHandler. All response headers including TASK_RESOURCE_USAGE now survive context restore.
Issues Resolved
[List any issues this PR will resolve]
Testing
Manual integration test — built OpenSearch 3.7.0-SNAPSHOT with security + query-insights plugins, created single-shard index, ran search, confirmed _insights/top_queries returns both entries in task_resource_usages:
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.