codeant-ai-for-open-source[bot] commented on code in PR #43424:
URL: https://github.com/apache/superset/pull/43424#discussion_r3836570695


##########
superset-frontend/src/components/Chart/chartAction.ts:
##########
@@ -648,16 +649,19 @@ export function handleChartDataResponse(
       case 200:
         // Query results returned synchronously, meaning query was already 
cached.
         return Promise.resolve(result);
-      case 202:
-        // Query is running asynchronously and we must await the results.
-        // When status is 202, result contains async event data (job_id, 
channel_id, etc.)
-        // which differs from QueryData. We cast through unknown to handle 
this safely.
-        // The optional signal lets a caller abort the wait (Stop pressed, 
chart
-        // superseded or unmounted), cancelling the job and avoiding leaked 
listeners.
-        return waitForAsyncData(
-          result as unknown as Parameters<typeof waitForAsyncData>[0],
-          signal,
-        ) as Promise<QueryData[]>;
+      case 202: {
+        // Query is running asynchronously as one GTF task per QueryObject. The
+        // 202 body is the async job ({task_ids}); await every task, then 
re-issue
+        // this request via `refetch` to read the now-cached results. The 
optional
+        // signal lets a caller abort the wait (Stop pressed, chart superseded 
or
+        // unmounted), cancelling the outstanding tasks.
+        if (!refetch) {
+          throw new Error(
+            'Async chart-data response (202) received without a refetch 
handler',
+          );
+        }
+        return waitForAsyncData(json as unknown as AsyncJob, refetch, signal);

Review Comment:
   **Suggestion:** Shared GTF tasks can be returned to multiple chart requests, 
but `waitForAsyncData` stores only one waiter per task ID. When this call 
registers a second request for an already-awaited shared task, it overwrites 
the first waiter, so only the latest chart request is resolved and the earlier 
chart remains pending indefinitely. The waiter registry must support multiple 
waiters per task ID or deduplicate completion notifications without overwriting 
subscribers. [race condition]
   
   <details>
   <summary><b>Severity Level:</b> Major ⚠️</summary>
   
   ```mdx
   - ❌ Concurrent charts sharing a task can remain indefinitely pending.
   - ⚠️ Affected charts never receive cached query results.
   - ⚠️ Shared task polling loses an earlier subscriber.
   ```
   </details>
   
   [![Use CodeAnt 
Skill](https://new-codeant-butcket.s3.us-west-1.amazonaws.com/badges/use-codeant-skill-flat-v2.svg)](https://docs.codeant.ai/cli/resolve-pr-comments-skill)
   <details>
   <summary><b>Prompt for AI Agent 🤖 </b></summary>
   
   ```mdx
   This is a comment left during a code review.
   
   **Path:** superset-frontend/src/components/Chart/chartAction.ts
   **Line:** 663:663
   **Comment:**
        *Race Condition: Shared GTF tasks can be returned to multiple chart 
requests, but `waitForAsyncData` stores only one waiter per task ID. When this 
call registers a second request for an already-awaited shared task, it 
overwrites the first waiter, so only the latest chart request is resolved and 
the earlier chart remains pending indefinitely. The waiter registry must 
support multiple waiters per task ID or deduplicate completion notifications 
without overwriting subscribers.
   
   Validate the correctness of the flagged issue. If correct, How can I resolve 
this? If you propose a fix, implement it and please make it concise.
   Once fix is implemented, also check other comments on the same PR, and ask 
user if the user wants to fix the rest of the comments as well. if said yes, 
then fetch all the comments validate the correctness and implement a minimal fix
   ```
   </details>
   <a 
href='https://app.codeant.ai/feedback?pr_url=https%3A%2F%2Fgithub.com%2Fapache%2Fsuperset%2Fpull%2F43424&comment_hash=9fecb64825fe65939dd786ab4521c2ff869f1525d874e53b9100ad3e42f672f2&reaction=like'>👍</a>
 | <a 
href='https://app.codeant.ai/feedback?pr_url=https%3A%2F%2Fgithub.com%2Fapache%2Fsuperset%2Fpull%2F43424&comment_hash=9fecb64825fe65939dd786ab4521c2ff869f1525d874e53b9100ad3e42f672f2&reaction=dislike'>👎</a>



##########
superset/tasks/guest.py:
##########
@@ -0,0 +1,69 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements.  See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership.  The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License.  You may obtain a copy of the License at
+#
+#   http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""Guest identity for Global Task Framework subscriptions.
+
+Embedded guest users have no ``ab_user`` row, so they cannot subscribe to tasks
+by ``user_id``. Instead they subscribe by a ``guest_key``: a stable, 
unguessable
+identity derived from their guest token, which the task filter honors to grant 
a
+guest visibility of the tasks it created or (via SHARED-scope dedup) joined.
+"""
+
+from __future__ import annotations
+
+import hashlib
+import hmac
+
+from flask import current_app
+
+from superset import security_manager
+from superset.utils import json
+
+
+def get_current_guest_subscriber_key() -> str | None:
+    """Return a stable subscriber key for the current guest, or ``None``.
+
+    ``None`` when the request is not an embedded guest (an authenticated user
+    subscribes by ``user_id`` instead). The key is an HMAC over the guest 
token's
+    stable identifying claims, keyed with the app ``SECRET_KEY`` so it is
+    unguessable to outside callers and reproducible for the same token across 
the
+    request that schedules a task and the polls that await it.
+    """
+    guest_user = security_manager.get_current_guest_user_if_guest()
+    if not guest_user:
+        return None
+    token = guest_user.guest_token
+    # ``iat``/``exp`` pin the key to a single token issuance; ``resources``/
+    # ``datasets``/``rev`` bind it to the granted scope, so tokens differing 
only
+    # in their allowlist or revocation version derive distinct keys.
+    message = json.dumps(
+        {
+            "user": token.get("user"),
+            "resources": token.get("resources"),
+            "iat": token.get("iat"),
+            "exp": token.get("exp"),
+            "aud": token.get("aud"),
+            "datasets": token.get("datasets"),
+            "rev": token.get("rev"),

Review Comment:
   **Suggestion:** The derived identity omits the token's `rls_rules` claim, 
even though RLS rules are part of the guest's effective authorization scope. 
Two tokens for the same user/resources but different RLS rules therefore 
receive the same `guest_key`, allowing one guest to pass the task visibility 
filter and observe the other guest's task status and metadata. Include all 
authorization-relevant claims, especially `rls_rules`, in the HMAC input. 
[security]
   
   <details>
   <summary><b>Severity Level:</b> Minor 🧹</summary>
   
   ```mdx
   - ⚠️ Guest task status metadata crosses RLS scopes.
   - ⚠️ `/api/v1/task/status_changes` exposes another guest’s progress.
   - ⚠️ Different row-level scopes share one task visibility identity.
   ```
   </details>
   
   [![Use CodeAnt 
Skill](https://new-codeant-butcket.s3.us-west-1.amazonaws.com/badges/use-codeant-skill-flat-v2.svg)](https://docs.codeant.ai/cli/resolve-pr-comments-skill)
   <details>
   <summary><b>Prompt for AI Agent 🤖 </b></summary>
   
   ```mdx
   This is a comment left during a code review.
   
   **Path:** superset/tasks/guest.py
   **Line:** 54:60
   **Comment:**
        *Security: The derived identity omits the token's `rls_rules` claim, 
even though RLS rules are part of the guest's effective authorization scope. 
Two tokens for the same user/resources but different RLS rules therefore 
receive the same `guest_key`, allowing one guest to pass the task visibility 
filter and observe the other guest's task status and metadata. Include all 
authorization-relevant claims, especially `rls_rules`, in the HMAC input.
   
   Validate the correctness of the flagged issue. If correct, How can I resolve 
this? If you propose a fix, implement it and please make it concise.
   Once fix is implemented, also check other comments on the same PR, and ask 
user if the user wants to fix the rest of the comments as well. if said yes, 
then fetch all the comments validate the correctness and implement a minimal fix
   ```
   </details>
   <a 
href='https://app.codeant.ai/feedback?pr_url=https%3A%2F%2Fgithub.com%2Fapache%2Fsuperset%2Fpull%2F43424&comment_hash=bd7924864e47f1d570bd8b85507b90118692b7cf1ba9595f0d8495cfe7f67811&reaction=like'>👍</a>
 | <a 
href='https://app.codeant.ai/feedback?pr_url=https%3A%2F%2Fgithub.com%2Fapache%2Fsuperset%2Fpull%2F43424&comment_hash=bd7924864e47f1d570bd8b85507b90118692b7cf1ba9595f0d8495cfe7f67811&reaction=dislike'>👎</a>



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