Skip to content

Allow storing scripts in multiple projects #130578

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

nielsbauman
Copy link
Contributor

This commit makes the ScriptService, the ScriptCache, and the stored
script APIs project-aware. By adding the project ID to the cache key in
the ScriptCache, we avoid data leakage between projects. The method
ScriptService#compile has a lot of usages, so we introduce a temporary
method that hard-codes the default project ID. Follow-up PRs will update
the remaining usages to pass the correct project ID.

This commit makes the `ScriptService`, the `ScriptCache`, and the stored
script APIs project-aware. By adding the project ID to the cache key in
the `ScriptCache`, we avoid data leakage between projects. The method
`ScriptService#compile` has a lot of usages, so we introduce a temporary
method that hard-codes the default project ID. Follow-up PRs will update
the remaining usages to pass the correct project ID.
@nielsbauman nielsbauman requested a review from a team as a code owner July 3, 2025 20:06
@nielsbauman nielsbauman added the :Core/Infra/Scripting Scripting abstractions, Painless, and Mustache label Jul 3, 2025
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (Team:Core/Infra)

@elasticsearchmachine elasticsearchmachine added v9.2.0 Team:Core/Infra Meta label for core/infra team labels Jul 3, 2025
@rjernst
Copy link
Member

rjernst commented Jul 3, 2025

ScriptService#compile has a lot of usages
Follow-up PRs will update the remaining usages to pass the correct project ID.

Compilation should normally be in the context of a user request. Shouldn't it then get the project id from the thread context?

@nielsbauman
Copy link
Contributor Author

Compilation should normally be in the context of a user request. Shouldn't it then get the project id from the thread context?

@rjernst, thanks for chiming in! We usually try to explicitly pass the project ID around and minimize the reliance on the thread context, as it can be difficult to track down where the project ID is supposed to be set in a call chain. Since there are a lot of usages all over the codebase here, I'm open to considering using the thread context. Can you think of any usages where compilation happens outside of the context of a user request? A perhaps counterintuitive example is cluster state update tasks; those are run without the thread context of the request. Do you happen to know if we do any script compilation in cluster state update tasks, for example? I can do some investigation if you don't already happen to know.

@rjernst
Copy link
Member

rjernst commented Jul 3, 2025

Can you think of any usages where compilation happens outside of the context of a user request?

One I'm not sure of is async search. I assume the search happens in the user context, even after being forked to the async threadpool as a task, but if not then that would be one. Otherwise, scripts are a way for users to customize functionality, so it wouldn't make sense to compile a script outside a user request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Core/Infra/Scripting Scripting abstractions, Painless, and Mustache >non-issue Team:Core/Infra Meta label for core/infra team v9.2.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants