Abdulrehman-PIAIC80387 commented on PR #42463:
URL: https://github.com/apache/superset/pull/42463#issuecomment-5127766488
Both flags are correct — thanks. Pushed `a5d642b` addressing them:
**Comment 1 (Critical, `SecurityError` swallowed):** `process_template` in
`jinja_context.py:807-848` does wrap `SecurityError` into
`SupersetSyntaxErrorException`. Now inspecting `ex.__cause__` and only raising
the soften-able `SupersetVirtualTableParseException` when the cause is
`jinja2.UndefinedError` — sandbox violations, template syntax errors, and
encoding errors keep raising the base `SupersetGenericDBErrorException` so
operators see them.
**Comment 2 (Major, static invalid SQL swallowed):** correct —
`SupersetParseError` fires on any invalid SQL, not just Jinja artifacts. Now
only softening the parse path when the input SQL contained Jinja markers (`{%`
or `{{`). Genuinely invalid static SQL (`SELECT INVALID FROM …`) keeps
hard-erroring — the existing `test_get_virtual_table_metadata_invalid_sql`
already covers that as a regression guard.
Added three new tests in `tests/unit_tests/connectors/sqla/test_utils.py`
covering the disambiguation:
- Jinja parse error → softened (`SupersetVirtualTableParseException`)
- Template `UndefinedError` → softened
- Template `SecurityError` → NOT softened (raises base
`SupersetGenericDBErrorException`)
Happy to iterate further if the disambiguation should live somewhere else.
--
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]
