rusackas opened a new pull request, #42597: URL: https://github.com/apache/superset/pull/42597
### SUMMARY This is a **test-only PR** opened as a TDD-style validation of issue #34543. #34543 (filed 2025-08) reports that embedded dashboards with multiple Jinja `url_param()` filters fail async chart-data cache retrieval with a `422 Unprocessable Entity` / "Error loading data from cache", while a single `url_param` works fine. The reporter (and dosubot) suspected a serialization mismatch between the Celery write phase and the web read phase. Root cause found: `SqlaTable.get_extra_cache_keys()` (`superset/connectors/sqla/models.py`) returns `list(set(extra_cache_keys))`. Python randomizes string hashing per-process (`PYTHONHASHSEED`), so the same set of `url_param()` values can iterate in a different order in the Celery worker process (which writes the query results to cache) than in the web process (which later re-derives the cache key to read them back). `hash_from_dict()` (`superset/utils/hashing.py`) only sorts **dict keys** via `json.dumps(..., sort_keys=True)` — it does not sort **list values** — so two `extra_cache_keys` lists with identical values in a different order hash to two different cache keys. A single-element list has only one possible order, which is exactly why the bug is only visible with 2+ url_params, matching the reported single-vs-multi-parameter split precisely. (This also matches a workaround dosubot mentioned in the issue thread: some users manually remove the `list(set(...))` dedup call as a local patch.) This PR adds one regression test on `QueryObject.cache_key()`: 1. **`test_cache_key_stable_regardless_of_extra_cache_keys_order`** — asserts the cache key is identical for two otherwise-equal query objects whose `extra_cache_keys` differ only in order. ### How to interpret CI - **CI red** (expected) — confirms the bug: the cache key currently changes when `extra_cache_keys` order changes, exactly as it would across two separate Python processes with different hash seeds. - **Likely fix**: sort the list before hashing, e.g. `sorted(extra_cache_keys, key=str)` in `SqlaTable.get_extra_cache_keys()`, or sort within `hash_from_dict`/`QueryObject.cache_key()` itself so any future extra_cache_keys producer is safe by construction. ### TESTING INSTRUCTIONS ```bash pytest tests/unit_tests/queries/query_object_test.py::test_cache_key_stable_regardless_of_extra_cache_keys_order -v ``` ### ADDITIONAL INFORMATION - [x] Has associated issue: closes #34543 - [ ] Required feature flags: `GLOBAL_ASYNC_QUERIES` (only needed to reproduce the end-to-end symptom; this test reproduces the root cause directly without it) - [ ] Changes UI - [ ] Includes DB Migration - [ ] Introduces new feature or API - [ ] Removes existing feature or API 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
