docs: clarify Query Based Dropdown List uses cached results

[Omastto1]

Summary

Adds a note to the "Query Based Dropdown List" section clarifying that dropdown values come from the last cached result of the source query — the source query is not re-executed when the parent query runs.

Why

This behavior is not documented but is non-obvious and causes confusion for dropdowns that need to be updated.

• A newly created source query produces an empty dropdown until it has been executed at least once.
• When the source query's latest_query_data_id is None, the /api/queries/<id>/dropdown endpoint raises an unhandled NoResultFound and returns a 500. The frontend silently catches it and shows "No options available" with no indication of why.
• To keep dropdown options current, the source query must be scheduled (or manually executed) after the underlying data changes.
• The same cached values are also used by the backend to validate the value submitted for a query-type parameter when executing a query via the API.

Evidence (from getredash/redash)

For reviewers who want to verify the claim — all paths are read-only DB lookups, no execution triggered:

• redash/models/parameterized_query.py:20-29 - _load_result reads query.latest_query_data_id via QueryResult.get_by_id_and_org
• redash/models/parameterized_query.py:32-36 - dropdown_values only calls _load_result
• redash/models/parameterized_query.py:160-164 - parameter validation uses dropdown_values - redash/handlers/query_results.py:194-201 - QueryResultDropdownResource calls dropdown_values only

Scope

Docs-only change. No code changes, no behavior changes.

[cubic-dev-ai]

No issues found across 1 file