Explore: Switching datasource at pane level does not update query-level datasource uid

Description When switching the datasource in the Explore pane picker, the pane-level datasource field is updated correctly, but the datasource field embedded inside each query object is not reset. As a result, all subsequent queries continue to use the previous datasource, even though the UI shows the new one is selected.

The only workaround is to force-refresh the browser or manually clear and re-enter the query expression, which triggers query object recreation.

Steps to Reproduce Open Explore Select datasource A and run any query (e.g. lvs_exporter_build_info) Switch to datasource B using the datasource picker at the top of the pane Run the same query again without modifying the query expression Expected Behavior After switching the datasource, all queries should be re-bound to the new datasource. The x-datasource-uid request header and the datasource.uid field inside each query object should reflect the newly selected datasource.

Actual Behavior The POST /api/ds/query request still carries the old datasource uid:

x-datasource-uid: bf654o51yhfr4b ← old datasource x-plugin-id: prometheus The URL panes parameter shows the inconsistency clearly:

{ "datasource": "dbaaef04-3f7e-42ac-b168-4292068a5057", "queries": [{ "datasource": { "type": "prometheus", "uid": "bf654o51yhfr4b" } }] } The pane-level datasource has been updated to the new uid, but the query-level datasource.uid still holds the old value. Grafana routes the query using the query-level uid, so the old datasource is queried.

Environment Grafana version: 12.2.1 Deployment: Kubernetes, multiple replicas Browser: Chrome 150 Both datasources are of type: Prometheus Workaround After switching the datasource, manually clear and re-type the query expression. This forces the query object to be recreated without the stale datasource field, and the next execution correctly uses the new datasource.

Force-refreshing the browser (Ctrl+Shift+R) also resolves the issue temporarily.