[BUGFIX] Fix exception_info nested under metric ID key instead of flat structure (#10849)#11878
Conversation
…t structure (great-expectations#10849) When a metric resolution fails (e.g. referencing a non-existent column), `graph_validate` passed the entire `metric_exception_info` dict—keyed by stringified metric IDs like `"('column_values.nonnull.condition', '...')"` — directly as the `exception_info` field of `ExpectationValidationResult`. This produced a nested structure: {"('column_values.nonnull.condition', '...')": {"raised_exception": true, ...}} instead of the documented flat structure: {"raised_exception": true, "exception_traceback": "...", "exception_message": "..."} Fix: extract the first ExceptionInfo object from the metric exception dict and pass it directly to ExpectationValidationResult so callers always see the expected flat exception_info shape. Fixes great-expectations#10849
👷 Deploy request for niobium-lead-7998 pending review.Visit the deploys page to approve it
|
|
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: creazyfrog |
…structure
After flattening exception_info from a metric-id-keyed dict to a plain
ExceptionInfo object, update the three integration tests that were
iterating .values() on the old nested structure to instead access
.get("raised_exception") / .get("exception_message") directly.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
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: creazyfrog, trivenzaa-admin |
…uotes
ExceptionInfo.__str__() uses json.dumps(), which escapes double quotes in
values (e.g. 'The column "b" ...' becomes 'The column \"b\" ...'). Tests
that checked for double-quoted substrings via str(result.exception_info)
therefore failed. Switch all such assertions to access
result.exception_info.get("exception_message", "") directly.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
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: creazyfrog, trivenzaa-admin |
for more information, see https://pre-commit.ci
|
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: creazyfrog, trivenzaa-admin |
2 participants
Summary
Fixes #10849
When a metric resolution fails (e.g. a validation expectation references a non-existent column on a Spark/Databricks datasource),
graph_validatepassed the entiremetric_exception_infodict directly as theexception_infofield ofExpectationValidationResult. Because that dict is keyed by stringified metric IDs (e.g."('column_values.nonnull.condition', '...')"), downstream consumers received a nested structure like:instead of the documented flat structure:
This broke any code that inspects
validation_result["results"][i]["exception_info"]programmatically (monitoring dashboards, alerting pipelines, etc.).Changes
great_expectations/validator/validator.py— In_resolve_metrics_and_identify_aborted_expectations, extract the firstExceptionInfoobject frommetric_exception_infoand pass it directly toExpectationValidationResultso callers always receive the flat{raised_exception, exception_traceback, exception_message}shape.tests/validator/test_validator.py— Updatetest_validator_with_exception_info_in_resultto assert the flat structure rather than the old nested-by-metric-ID structure.How to reproduce
Test plan
test_validator_with_exception_info_in_resultintests/validator/test_validator.pyto assert the flatexception_infostructureexception_infowith the correctraised_exception,exception_traceback, andexception_messagekeys