EnxDev commented on code in PR #42472:
URL: https://github.com/apache/superset/pull/42472#discussion_r3674010971
##########
superset/subjects/utils.py:
##########
@@ -176,6 +296,80 @@ def get_or_create_role_subject(role_id: int) -> Subject |
None:
return get_role_subject(role_id)
+def get_group_subject(group_id: int) -> Subject | None:
+ """Get the GROUP-type Subject for a given group ID."""
+ return (
+ db.session.query(Subject)
+ .filter_by(
+ group_id=group_id,
+ type=SubjectType.GROUP,
+ )
+ .first()
+ )
+
+
+def get_or_create_group_subject(group_id: int) -> Subject | None:
+ """Get or create the GROUP-type Subject for a given group ID.
+
+ Mirrors ``get_or_create_role_subject``: a group that exists but has no
+ Subject row yet (e.g. created before the sync hooks were installed and not
+ yet backfilled) is synced on demand rather than skipped. Returns ``None``
+ only when no such group exists.
+
+ The insert runs inside a SAVEPOINT. ``Subject.group_id`` is unique, so a
+ concurrent request backfilling the same group would otherwise fail this
+ flush with an ``IntegrityError`` and poison the surrounding transaction. On
+ that conflict the savepoint rolls back and the row the other request wrote
+ is reloaded. Any ``IntegrityError`` that did *not* leave a matching row is
+ re-raised rather than swallowed — it isn't the expected unique-key race, so
+ masking it would silently drop the group from the resulting viewer set.
+ """
+ if subject := get_group_subject(group_id):
+ return subject
+
+ from sqlalchemy.exc import IntegrityError
+
+ from superset import security_manager
+ from superset.subjects.sync import sync_group_subject
+
+ group = db.session.get(security_manager.group_model, group_id)
+ if not group:
+ return None
+
+ try:
+ with db.session.begin_nested():
+ sync_group_subject(group)
+ except IntegrityError:
Review Comment:
Fixed. You're right that begin_nested() flushes pending session state before
the SAVEPOINT, so unrelated pending work was being flushed inside the try. I
now call db.session.flush() explicitly before entering the savepoint — any
unrelated failure surfaces there and propagates, and the savepoint's flush
carries only the Subject insert, so the except IntegrityError sees only this
group's uniqueness conflict. Combined with the existing "re-raise unless the
row now exists" guard, an unrelated integrity error can no longer be mistaken
for (or masked as) the concurrent-insert race.
##########
superset/subjects/utils.py:
##########
@@ -176,6 +296,80 @@ def get_or_create_role_subject(role_id: int) -> Subject |
None:
return get_role_subject(role_id)
+def get_group_subject(group_id: int) -> Subject | None:
+ """Get the GROUP-type Subject for a given group ID."""
+ return (
+ db.session.query(Subject)
+ .filter_by(
+ group_id=group_id,
+ type=SubjectType.GROUP,
+ )
+ .first()
+ )
+
+
+def get_or_create_group_subject(group_id: int) -> Subject | None:
+ """Get or create the GROUP-type Subject for a given group ID.
+
+ Mirrors ``get_or_create_role_subject``: a group that exists but has no
+ Subject row yet (e.g. created before the sync hooks were installed and not
+ yet backfilled) is synced on demand rather than skipped. Returns ``None``
+ only when no such group exists.
+
+ The insert runs inside a SAVEPOINT. ``Subject.group_id`` is unique, so a
+ concurrent request backfilling the same group would otherwise fail this
+ flush with an ``IntegrityError`` and poison the surrounding transaction. On
+ that conflict the savepoint rolls back and the row the other request wrote
+ is reloaded. Any ``IntegrityError`` that did *not* leave a matching row is
+ re-raised rather than swallowed — it isn't the expected unique-key race, so
+ masking it would silently drop the group from the resulting viewer set.
+ """
+ if subject := get_group_subject(group_id):
+ return subject
+
+ from sqlalchemy.exc import IntegrityError
+
+ from superset import security_manager
+ from superset.subjects.sync import sync_group_subject
+
+ group = db.session.get(security_manager.group_model, group_id)
+ if not group:
+ return None
+
+ try:
+ with db.session.begin_nested():
+ sync_group_subject(group)
+ except IntegrityError:
Review Comment:
Fixed. You're right that begin_nested() flushes pending session state before
the SAVEPOINT, so unrelated pending work was being flushed inside the try. I
now call db.session.flush() explicitly before entering the savepoint — any
unrelated failure surfaces there and propagates, and the savepoint's flush
carries only the Subject insert, so the except IntegrityError sees only this
group's uniqueness conflict. Combined with the existing "re-raise unless the
row now exists" guard, an unrelated integrity error can no longer be mistaken
for (or masked as) the concurrent-insert race.
--
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]
