Skip to content

fix(StateManager): catch TypeError in _decode_state for non-object JSON - #379

Closed
Jah-yee wants to merge 1 commit into
allen0099:masterfrom
Jah-yee:fix/state-typeerror
Closed

Jah-yee wants to merge 1 commit into
allen0099:masterfrom
Jah-yee:fix/state-typeerror

Conversation

@Jah-yee

@Jah-yee Jah-yee commented Sep 29, 2026

Copy link
Copy Markdown

Summary

In , raises when is valid JSON but not a dict object (e.g., a JSON array or string ). Only was caught, leaving unhandled.

Fix

Catch both and in the final try block of .

Testing

The fix was validated against the reported scenario: when is a non-dict JSON value, raises which is now caught and re-raised as .

Fixes #368

StateData(**state_dict) raises TypeError when state_dict is valid JSON
but not a dict (e.g., a list [1, 2] or string "x"). Only ValueError
was caught, leaving TypeError unhandled.

Fixes: allen0099#368
@allen0099

Copy link
Copy Markdown
Owner

Thanks for looking at #368. The one-line change points in the right direction, but it is missing what the issue asks for: a test for each of validate_state, get_state_metadata and consume_state, and a changelog fragment (changelog.d/368.fixed.md, see docs/DEVELOPMENT.md#changelog-fragments). Catching every TypeError around StateData(**...) is also broader than needed; an isinstance(state_dict, dict) check after json.loads gives a clearer error and keeps the dict[str, Any] annotation honest.

We will fix #368 ourselves in a separate PR, so I am closing this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

StateManager: a stored state that is JSON but not an object raises TypeError instead of StateDataError

2 participants