Fix incorrect exception_info structure when raised_exception is True#11657
Fix incorrect exception_info structure when raised_exception is True#11657Mr-Neutr0n wants to merge 1 commit intogreat-expectations:developfrom
Conversation
When metric resolution errors occur during validation, the exception_info
dict was being passed with metric identifier keys wrapping the actual
exception data, e.g. {"('column_values.nonnull.condition', ...)" : {...}}.
This made it impossible to programmatically check result.exception_info
for raised_exception, exception_message, or exception_traceback since
the keys were unpredictable metric identifiers rather than the expected
flat structure.
The fix extracts the ExceptionInfo from the first failing metric and
passes it directly, consistent with all other exception handling paths
in the validator.
Fixes great-expectations#10849
|
| Name | Link |
|---|---|
| 🔨 Latest commit | e21b48f |
|
A new contributor, HUZZAH! Welcome and thanks for joining our community. In order to accept a pull request we require that all contributors sign our Contributor License Agreement. We have two different CLAs, depending on whether you are contributing to GX in a personal or professional capacity. Please sign the one that is applicable to your situation so that we may accept your contribution: Individual Contributor License Agreement v1.0 Once you have signed the CLA, you can add a comment with the text Please reach out to the #gx-community-support channel, on our Slack if you have any questions or if you have already signed the CLA and are receiving this message in error. Users missing a CLA: mr-neutr0n |
1 participant
Summary
Fixes #10849
When a metric resolution error occurs during validation (e.g. referencing a non-existent column), the
exception_infodict on the result gets structured as:{"('column_values.nonnull.condition', '242ce...', ())": {"raised_exception": True, "exception_traceback": "...", "exception_message": "..."}}instead of the expected flat structure:
{"raised_exception": True, "exception_traceback": "...", "exception_message": "..."}This happens because
_resolve_suite_level_graph_and_process_metric_evaluation_errorsinvalidator.pypasses the rawmetric_exception_infodict (keyed by metric ID strings) directly as theexception_infoargument toExpectationValidationResult. Every other exception handling path in the validator correctly passes a singleExceptionInfoobject.The fix extracts the
ExceptionInfofrom the first failing metric and passes it directly, making the structure consistent across all code paths. This matches how the renderers inexpectation.pyalready handle this case — they iterate the dict and break after the first entry.Changes
great_expectations/validator/validator.py: Extract the firstExceptionInfovalue frommetric_exception_infobefore passing it toExpectationValidationResult, instead of passing the entire dict keyed by metric identifiers.Test plan
result.exception_info["raised_exception"]returnsTruedirectly (no nested key)result.exception_info["exception_message"]andresult.exception_info["exception_traceback"]are accessible at the top levelexpectation.pystill work (they check"raised_exception" in result.exception_infofirst, which now succeeds on the first branch)get_exception_info()itself is unchanged