Bug description

There is a regression in the PR fix(Jinja): Extra cache keys to consider vars with set #30549 . I mentioned it as a comment within the PR but I guess since it's merged I'm filing a proper bug report.

This PR breaks are existing usage of RLS (thank heavens one for our campus users notified us 😅 ). This is our input string:

campus_id IN UNNEST( {{ cache_key_wrapper(current_user_campus_ids()) }} )

which doesn't match using the pattern : cache_key_wrapper\([^()]*\), but does using the old one (v4.0.2): cache_key_wrapper\(.*\).

The function we use looks as follows:

def current_user_campus_ids() -> list[int]:
    """
    Get the list of campus ids associated with the current user
    """
    user: FortyTwoUser = g.user
    return user.campus_ids()

and is populated using the oauth2 jwt from keycloak. Is the only workaround to monkey patch the jinja ExtraCache processor to add our macro within? How is the cache_key_wrapper() to be used if it can't invoke another function?

Screenshots/recordings

No response

Superset version

4.1.2

Python version

3.10

Node version

I don't know

Browser

Chrome

Additional context

No response

Checklist

  • [x] I have searched Superset docs and Slack and didn't find a solution to my problem.
  • [x] I have searched the GitHub issue tracker and didn't find a similar bug report.
  • [x] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

Comment From: dosubot[bot]

This regression is due to a change in the regex used by Superset to detect cache key wrappers in Jinja templates—it now only allows simple, non-nested expressions like cache_key_wrapper(foo) and blocks nested calls like cache_key_wrapper(current_user_campus_ids()) that worked in previous versions. This breaks use cases like yours for RLS and dynamic user-based cache keys. There’s currently no official workaround or extensibility for this in the code or docs, and no open issues or discussions about it in the repo.

Monkey patching the Jinja ExtraCache processor is the only available workaround if you need to restore the previous behavior, since the regex restriction is hardcoded and there’s no config or plugin hook for extending cache key computation. If you go this route, be aware it’s an unsupported hack and could break with future updates. Otherwise, you’d need to refactor your templates to avoid nested calls, but that may not be possible for your use case.

For reference, here’s the relevant implementation and restriction in the code:
cache_key_wrapper and regex in ExtraCache
And the intended usage in the docs:
SQL templating and cache_key_wrapper

If you need to keep your current pattern, monkey patching is your only option until the project provides a more flexible or documented solution.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X