fix(tests): stale shop_for_data assertion; chore(release): bump version to 6.1.12 - #351
Merged
Merged
Conversation
…s omitted
`MetadataExpert.declassify_metadata_element(guid, classification_name, body=None)`
declares `body` as Optional but calls `.model_dump()` on it unconditionally, so
omitting it raises `AttributeError: 'NoneType' object has no attribute
'model_dump'` and the classification is left in place.
Worse than an ordinary signature bug because the failure is silent at the
caller. A caller that wraps the call defensively — reasonable, since removing a
classification that is already absent should not be fatal — swallows the
AttributeError and believes the removal happened. Measured live: kinds before
['Task'], declassify raises, kinds after ['Task'].
In our case the element then carried TWO kind classifications at once
(['Task', 'PersonalProject']) and a check that only asked "is the new
classification present?" reported success. The wrong-but-plausible state was
invisible until the element was read back for BOTH names.
Workaround verified: passing `{"class": "MetadataSourceRequestBody"}` explicitly
makes it work (kinds after: []). Candidate fix is to default the body when None,
matching the declaration.
`classify_metadata_element` and `reclassify_metadata_element` sit beside it with
the same Optional body declaration and are worth checking — we pass a body to
both so we have not hit them.
Logged, not fixed, per the standing rule for this repo.
Found in trellis/packages/resource-explorer's investigation reclassifier, which
now passes the body and additionally asserts the OLD classification is gone
rather than only that the new one arrived.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
…e(release): bump version to 6.1.12
test_handle_shop_for_data_option_success asserted the Digital-Product-Catalog-MyE
search call's params as {"search_string": "*"} only. PR odpi#346 added a
metadata_element_subtypes: ["DigitalProduct", "DigitalProductFamily"] filter to
that call; the test was never updated to match, so it failed deterministically
(not flaky) on every run since -- this is what blocked the v6.1.11 release
workflow's PyPI publish step (build never ran; see release run 34252940497).
Also bumps to 6.1.12: PyPI already had a 6.1.11 published at 2026-09-08T02:15
UTC, ~14.5h before this repo's v6.1.11 tag/PR merged, with different (older)
content -- a pre-existing version collision unrelated to this fix. 6.1.12 is
the first clean, unused version number.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KYNxABE3SRUT5cXbpmrfU2
Signed-off-by: Dan Wolfson <dan.wolfson@pdr-associates.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
test_handle_shop_for_data_option_success, which asserted theDigital-Product-Catalog-MyEsearch call'sparamsas{"search_string": "*"}only. PR My_Egeria pull request #346 added ametadata_element_subtypes: ["DigitalProduct", "DigitalProductFamily"]filter to that call; the test was never updated to match, so it failed
deterministically (not flaky) on every run since. This is what blocked the
v6.1.11tag's release workflow at the unit-test step, before it everreached the PyPI publish job — see run 34252940497.
6.1.12. PyPI already had a6.1.11published at2026-09-08T02:15UTC — ~14.5h before this repo's ownv6.1.11tag/PR(feat(pyegeria,dr-egeria): add Data Standards types (Egeria PR #9300) #349/chore(release): bump version to 6.1.11 #350) merged, with different (older) content. That's a pre-existing
version collision unrelated to this fix;
6.1.12is the first clean,unused version number.
Test plan
pytest tests/micro-tests/my_profile/test_shop_for_data_handler.pypassespytest tests/micro-tests/passes (0 failures)🤖 Generated with Claude Code