Skip to content

Keep response fields this version does not know, and release 2.9.0 - #619

Merged
jmtts merged 1 commit into
mainfrom
claude/github-issue-priority-8dfztp
Oct 16, 2026
Merged

jmtts merged 1 commit into
mainfrom
claude/github-issue-priority-8dfztp

Conversation

@werk24

@werk24 werk24 commented Oct 14, 2026

Copy link
Copy Markdown
Contributor

New fields reach the API before they reach every installed copy of this library. Until now a client older than the API dropped every field its models did not declare, without any message, so a new field just never showed up and nothing said why. This pull request changes that and bumps the version, so the fields added since 2.8.0 can go to PyPI.

What changed

  • Unknown fields are kept. A v2 answer (payload_dict of an ASK message) is parsed with fields the model does not declare kept on it, as plain data under their own names: response.o_ring_grooves, or all of them in response.model_extra, nested items included. This uses pydantic's per-call model_validate(..., extra="allow"), available from pydantic 2.12, the floor pyproject.toml already sets.
  • The first time a field is seen, a warning names it. One werk24 logger warning per new field, listing paths such as slots[].orientation and saying pip install -U werk24. It is once per field per process, not once per message.
  • The models themselves are unchanged. Built directly, they still drop unknown fields, and model_dump() still leaves out the ones that were kept. So code that builds responses from these models sends exactly what it sent before.
  • An answer that cannot be read is now logged. For example, a new enum member. The answer still stays the plain dict the server sent, as before, but a warning now gives the first failing location, once per kind of failure.
  • read_drawing_sync return type documented. It returns a list of the ASK messages, with each answer in payload_dict, and has done since 2.7.0 (before that it returned the payloads themselves). The README gains a short "When the API is newer than your werk24" paragraph.
  • Version 2.8.0 → 2.9.0. Since 2.8.0, main has added slots and retaining_ring_grooves to the features response, RetainingRingSide, the general tolerance note contents and linear rules, and the priority level names. It has also removed two things (see question 1).

Draft release notes for 2.9.0

  • Added: ResponseFeaturesComponentDrawing.slots (2x Slot 14x15) and .retaining_ring_grooves (DIN 471 30x1,5), RetainingRingSide, threaded center holes, and the contents and linear rules of general tolerance notes.
  • Added: response fields this version does not know are kept on the response (model_extra) and named in a warning, instead of being dropped.
  • Changed: priority levels are named Express (PRIO1), Priority (PRIO2) and Best-effort (PRIO3); confidence_min is documented as no longer applied.
  • Removed: the v1 CANVAS_TABLES ask (W24AskCanvasTables) and TechreadException.reason.

Tests run

  • .venv/bin/python -m pytest on Python 3.13: 1035 passed, 5 skipped (the credential-gated live tests).
  • The new tests/test_unknown_response_fields.py (7 tests), test_standard_features.py, test_fasteners.py and test_read_drawing_sync.py on Python 3.10.20 with pydantic 2.12.0, the floor CI and pyproject.toml allow: 55 passed.
  • The new tests fail against the parser without this change.

Questions for the owner

Three questions. None blocks the merge; the second decides when the fields reach PyPI.

  1. Call this release 2.9.0, or 3.0.0?

    • Since 2.8.0, main removed two public names: the v1 CANVAS_TABLES ask (W24AskCanvasTables) and the reason attribute of TechreadException. Code that uses either one breaks on upgrade, whatever the number says.
    • Strict semantic versioning would make that 3.0.0. Releases here have so far moved the minor number, and the removed ask is no longer served.
    • Recommendation: 2.9.0, with both removals listed under "Removed" in the release notes.
  2. Publish to PyPI right after the merge?

    • Publishing runs when a GitHub release is created (python-publish.yml). Until then pip install -U werk24 keeps installing 2.8.0, which has neither slots nor retaining_ring_grooves.
    • Recommendation: yes. Create release v2.9.0 from main with the notes above as soon as this is merged.
  3. Leave the kept fields out of model_dump(), as now?

    • They are reachable as attributes and in model_extra, and the warning says to upgrade. Putting them into model_dump() as well would mean changing the models' configuration, which also changes what code that builds these models sends.
    • Recommendation: yes, leave them out. The warning and an upgrade cover it.

Not questions, for after the release:

  • Check that PyPI shows 2.9.0 and that pip install -U werk24 in a clean environment gets slots and retaining_ring_grooves.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NefPiavfYxvDzX5U9n1Bzm


Generated by Claude Code

A client older than the API used to drop every field its models did not
declare, without a word, so a new field simply never appeared. A v2
answer is now parsed with those fields kept on the model, as plain data
under their own names (response.<field>, response.model_extra), and the
first time each one is seen a warning names it and says to upgrade.

The models' own configuration is unchanged: built directly they still
drop unknown fields, and model_dump() still leaves kept ones out.

An answer the client cannot read at all (a new enum member, say) still
stays the plain dict the server sent, but is now logged too, once per
kind of failure.

Documents what read_drawing_sync returns (the ASK messages, with the
answer in payload_dict) and bumps the version to 2.9.0, which carries
slots and retaining_ring_grooves to PyPI.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NefPiavfYxvDzX5U9n1Bzm
@jmtts
jmtts merged commit 101afb7 into main Oct 16, 2026
7 checks passed
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.

3 participants