bito-code-review[bot] commented on code in PR #40292:
URL: https://github.com/apache/superset/pull/40292#discussion_r4088363108


##########
superset-frontend/src/components/ErrorMessage/OAuth2RedirectMessage.tsx:
##########
@@ -106,21 +106,60 @@ export function OAuth2RedirectMessage({
   const dispatch = useDispatch();
   const lastHandledTabIdRef = useRef<string>();
 
+  // `chartList` is rebuilt from `Object.keys` on every store update; keeping
+  // the listener state in a ref avoids tearing down/recreating the
+  // BroadcastChannel on each render and the race window that comes with it.
+  const latestStateRef = useRef({
+    source,
+    query,
+    chartId,
+    chartList,
+    dashboardId,
+    errorMitigationFunction,
+  });
+  latestStateRef.current = {
+    source,
+    query,
+    chartId,
+    chartList,
+    dashboardId,
+    errorMitigationFunction,
+  };

Review Comment:
   <div>
   
   
   <div id="suggestion">
   <div id="issue"><b>Stale state in long-lived effect</b></div>
   <div id="fix">
   
   `latestStateRef` decouples `handleOAuthComplete` from renders, but the 
effect (deps `[extra.tab_id, dispatch]`, line 212) never re-subscribes when 
`source`/`query`/`chartList`/`errorMitigationFunction` change. A signal 
arriving after a state change is handled with stale values, and `handled` (set 
from that stale decision) blocks later signals for the effect's lifetime. 
Consider re-subscribing on state changes or versioning the ref snapshot.
   </div>
   
   
   </div>
   
   
   
   
   <small><i>Code Review Run #ebcdd2</i></small>
   </div>
   
   ---
   Should Bito avoid suggestions like this for future reviews? (<a 
href=https://alpha.bito.ai/home/ai-agents/review-rules>Manage Rules</a>)
   - [ ] Yes, avoid them



##########
superset-frontend/src/components/ErrorMessage/OAuth2RedirectMessage.tsx:
##########
@@ -106,21 +106,60 @@ export function OAuth2RedirectMessage({
   const dispatch = useDispatch();
   const lastHandledTabIdRef = useRef<string>();
 
+  // `chartList` is rebuilt from `Object.keys` on every store update; keeping
+  // the listener state in a ref avoids tearing down/recreating the
+  // BroadcastChannel on each render and the race window that comes with it.
+  const latestStateRef = useRef({
+    source,
+    query,
+    chartId,
+    chartList,
+    dashboardId,
+    errorMitigationFunction,
+  });
+  latestStateRef.current = {
+    source,
+    query,
+    chartId,
+    chartList,
+    dashboardId,
+    errorMitigationFunction,
+  };
+
   useEffect(() => {
+    // Guard against duplicate dispatches if both the BroadcastChannel and the
+    // storage fallback ever deliver the same completion.
+    let handled = false;
     const handleOAuthComplete = (tabId?: string) => {
-      if (tabId !== extra.tab_id || tabId === lastHandledTabIdRef.current) {
+      if (
+        tabId !== extra.tab_id ||
+        tabId === lastHandledTabIdRef.current ||
+        handled
+      ) {
         return;
       }
-
-      if (errorMitigationFunction) {
-        errorMitigationFunction();
-      } else if (source === 'sqllab' && query) {
-        dispatch(reRunQuery(query));
-      } else if (source === 'explore') {
-        dispatch(triggerQuery(true, chartId));
-      } else if (source === 'dashboard') {
-        dispatch(onRefresh(chartList.map(Number), true, 0, dashboardId));
-      } else if (source === 'crud') {
+      const {
+        source: src,
+        query: q,
+        chartId: cId,
+        chartList: cList,
+        dashboardId: dId,
+        errorMitigationFunction: mitigate,
+      } = latestStateRef.current;
+      // `handled`/`lastHandledTabIdRef` are only set below, after this whole
+      // chain, and only reached when a branch actually dispatches — so a
+      // signal that arrives before state is ready (e.g. `query` still null
+      // in SQL Lab) falls through to the catch-all `return` and a later
+      // fallback signal can still succeed.
+      if (mitigate) {
+        mitigate();
+      } else if (src === 'sqllab' && q) {
+        dispatch(reRunQuery(q));
+      } else if (src === 'explore') {
+        dispatch(triggerQuery(true, cId));
+      } else if (src === 'dashboard') {
+        dispatch(onRefresh(cList.map(Number), true, 0, dId));

Review Comment:
   <div>
   
   
   <div id="suggestion">
   <div id="issue"><b>Unguarded optional dashboardId</b></div>
   <div id="fix">
   
   `dId` comes from `state.dashboardInfo?.id` (lines 102-104), so it can be 
`undefined`; `onRefresh`'s `dashboardId` parameter is optional 
(`dashboardState.ts:869-876`). With `src === 'dashboard'` before 
`dashboardInfo` is loaded, the refresh dispatches with `undefined` and silently 
no-ops. Guard the branch on `dId !== undefined` or skip dispatch when absent.
   </div>
   
   
   </div>
   
   
   
   
   <small><i>Code Review Run #ebcdd2</i></small>
   </div>
   
   ---
   Should Bito avoid suggestions like this for future reviews? (<a 
href=https://alpha.bito.ai/home/ai-agents/review-rules>Manage Rules</a>)
   - [ ] Yes, avoid them



-- 
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]

Reply via email to