feat: allow certain exceptions to commit

[betodealmeida]

SUMMARY

SIP-99 introduced in #24969 the amazing @transaction decorator, which transparently manages transactions in Superset in order to avoid eager commits.

SIP-85 introduced a mechanism for authenticating to databases via OAuth2, using exceptions to signalize to the frontend from deep in the backend that the user needs to authenticate by following a link. These exceptions are benign, and carry in their extra payload (see SIP-40) the URL used for authentication, among others.

Because of this, when adding a database that has OAuth2 enabled we need to allow certain exceptions to still commit, while raising them. This allows the database to be created succesfully, while signalizing to the user that they still need to authenticate. This is needed because OAuth2 tokens are stored associated with a database ID, so it must exist a priori.

This PR changes the @transaction decorator to allow an optional group of exceptions that should trigger a commit before being re-raised. It's part of a bigger work to add support for OAuth2 to Snowflake, still in progress but already tested end-to-end.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

N/A

TESTING INSTRUCTIONS

Added unit tests for the @transaction decorator, covering the old use cases and the new one.

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[michael-s-molina]

@betodealmeida Not using exceptions to control flow is probably the top 10 best practice. Is it possible to change the code to signalize to the frontend that the user needs to authenticate using other means? I'm really worried about this change as it might generate even more cases where exceptions are used to control flow.

[betodealmeida]

@michael-s-molina while I recognize it's normally an anti-pattern, no rule is 100% correct (an example where it can be useful).

For OAuth2 we're basically building a fancy 403 response that has information about how to proceed. We need to let the exception bubble up to the Flask error handler so that we can build a proper SIP-40 compliant error payload, which is what triggers OAuth2 in the frontend side. The benefit of this approach is that we can trigger OAuth2 without having to modify every API that might need it — instead all we need to do is attach a ErrorMessageWithStackTrace to the DOM.