bito-code-review[bot] commented on code in PR #42938:
URL: https://github.com/apache/superset/pull/42938#discussion_r3744964232
##########
superset/utils/rls.py:
##########
@@ -181,6 +182,12 @@ def collect_rls_predicates_for_sql(
}
)
except Exception:
- # If we can't parse the SQL, return empty list
- # This ensures RLS application failure doesn't break caching
- return []
+ # If we can't parse the SQL, we can't tell which (if any) RLS
+ # predicates would apply, so we can't contribute a meaningful cache
+ # key component. Returning an empty list here would make every
+ # user's failure collapse onto the same (missing) contribution,
+ # which is unsafe when different users have different RLS scopes on
+ # the underlying tables. Fall back to a per-user marker instead, so
+ # the cache key still varies by user even though we don't know the
+ # actual predicates.
+ return [f"rls-predicate-parse-failed-for-user-{get_user_id()}"]
Review Comment:
<!-- Bito Reply -->
The reviewer's suggestion to replace the generic `Exception` catch with
specific exception types is a standard practice to avoid masking unexpected
errors. However, if the intention is to catch all potential parsing errors from
the `sqlglot` library to ensure the fallback mechanism always triggers, keeping
the broad `Exception` catch is acceptable. You may choose to ignore this
suggestion if the current implementation is necessary for the required
robustness.
**superset/utils/rls.py**
```
except Exception:
# If we can't parse the SQL, we can't tell which (if any) RLS
# predicates would apply, so we can't contribute a meaningful cache
# key component. Returning an empty list here would make every
# user's failure collapse onto the same (missing) contribution,
# which is unsafe when different users have different RLS scopes on
# the underlying tables. Fall back to a per-user marker instead, so
# the cache key still varies by user even though we don't know the
# actual predicates.
return [
f"rls-predicate-parse-failed-for-user-{get_user_id()}"
]
```
--
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]
