Merged
Conversation
…sion tests - Enable number->string coercion for string fields (e.g. playEvents.base) - Coerce RunnerMovement.isOut null -> false - Accept person dicts for PlayEvent.umpire and linescore.offense first/second/third - Allow reviewDetails.additionalReviews to be string or list - Allow HitCoordinates x/y to be null - Add/expand regression tests keyed to reported gamepk IDs
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.
Why
MLB’s live game payloads are not fully type-consistent in the wild (e.g. playEvents.base can be an int, some fields can be null, and some “string” fields can return embedded person objects). With Pydantic v2, these inconsistencies can hard-fail validation and cause mlbstatsapi.get_game(...).gamedata to be rejected for specific gamePks reported by users.
What
Overview of the changes made
Hardened model parsing to tolerate known MLB Stats API inconsistencies:
Coerce numeric values into string fields (fixes playEvents.*.base int→str failures).
Coerce RunnerMovement.isOut null → False.
Accept person objects for fields that sometimes return dicts (e.g. PlayEvent.umpire, linescore.offense.first/second/third).
Allow reviewDetails.additionalReviews to be either a string or a list.
Allow hit coordinate values (coordinates.x/y) to be null.
Added regression tests keyed to user-reported gamePk IDs in tests/test_gamepk_validation_regressions.py.
Version bump to 0.7.2 in pyproject.toml.
Tests
poetry run pytest -q tests/
Result: 191 passed, 2 skipped
Risk and impact
What is the risk level of the change and why?
Normal
These changes relax/coerce a few model field types to match real API behavior. While targeted, it can slightly broaden accepted inputs.
What is the impact if something does go wrong with this PR?
Parsing of some game payloads could become less strict than intended (potentially masking upstream data issues), or downstream consumers could see different types (e.g. umpire populated as a Person object instead of a string in cases where the API returns a dict).