EnxDev commented on code in PR #40968:
URL: https://github.com/apache/superset/pull/40968#discussion_r3395326799
##########
superset-frontend/src/core/views/index.ts:
##########
@@ -75,6 +75,11 @@ const registerView: typeof viewsApi.registerView = (
viewRegistry.set(id, { view, location, provider });
const ids = locationIndex.get(location) ?? new Set();
+ // Re-registering an existing id must reflect its new recency. A Set
preserves
+ // first-insertion order and `add` is a no-op for an existing member, so
delete
+ // first to move the id to the end. Consumers that select the most-recently
+ // registered view (e.g. the chatbot resolver) depend on this ordering.
+ ids.delete(id);
ids.add(id);
Review Comment:
Re-registration of a view id is not a runtime path in this branch — the
loader never disposes views (lifecycle deferred, deactivateExtension removed),
and extension add/delete takes effect on a full page reload that resets the
registry. So neither the ordering-on-reregister nor the stale-disposal scenario
is reachable. Reverted the recency/token handling; it should land alongside a
disposing deactivate path if that's introduced.
--
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]
