[bfrancojr]

Fixes #40, by the option the owner chose there (lift upb's limit for our own parse).

What changes

A PXF document 100 levels deep with a Timestamp (or any literal-written well-known type) at the bottom now decodes, as protowire-go decodes it and as trendvidia/protowire#537 decided. Before, every decoder raised upb's DecodeError on it. A max_nesting_depth raised past 100 now works too. Before, it hit the same wall.

The cause: the native decoder returns PB bytes and Python loads them with upb. A literal is no PXF level but one PB level, so 100 PXF levels can be 101 PB levels. upb refuses anything past 100.

The fix is a new protowire/_upb.py, whose load replaces the five msg.Clear(); msg.MergeFromString(raw) sites (unmarshal, unmarshal_full, DatasetReader.scan, bind_row, sbe.Codec.unmarshal). Normal parses are unchanged. When upb refuses the bytes for depth alone, load clears the message, turns on upb's SetAllowOversizeProtos, parses again, and restores the switch.

• In upb's source the switch sets only the decode depth limit, to 65535 (python/message.c:1470, protobuf v36.2).
• The switch is process-wide with no getter. load probes it with a 101-level message and turns it off afterwards only if it found it off.
• protowire-cpp still enforces the caller's max_nesting_depth. So this lifts upb's second, stricter check on bytes we produced, not the real limit.

Caveats

• Another thread's parse during the retry also gets the lifted limit. A thread calling SetAllowOversizeProtos(True) during it may find it turned back off. This repo builds no free-threaded wheels.
• google._upb is private. test_the_switch_still_exists fails first if a protobuf release drops the switch.

Evidence

Built from this branch into a fresh venv (protowire-cpp v2.1.0, protobuf 7.36.2, CPython 3.15, macOS arm64): pytest tests → 209 passed, the 200 from main plus 9 new in tests/test_upb_depth.py:

• test_upb_alone_refuses_the_document: the native decoder's bytes for the depth-100 Timestamp document fail a plain MergeFromString with upb_DecodeOptions_MaxDepth. This pins the problem. If upb ever raises its own limit, this test fails and the fix can go.
• test_a_literal_at_the_limit_decodes (unmarshal, unmarshal_full): a chain of 100 levels, t.seconds == 1704067200.
• test_the_limit_itself_is_still_enforced: 101 levels → ValueError ... MaxNestingDepth=100.
• test_a_raised_limit_decodes_past_100: 300 levels decode with max_nesting_depth=300; 299 refuses them.
• test_the_switch_is_turned_back_off, test_a_callers_switch_is_left_on, test_the_message_is_replaced_not_merged.

The switch-restore test caught a bug in the first version of the probe. It built 100 levels below the root, which upb accepts, so the probe always read "on" and load never turned the switch back off. The probe now builds 101 levels, and reads off → False, on → True.

Not covered here: the corpus row #537 asks for (a 100-level document ending in a Timestamp, expect: accept) doesn't exist in the spec yet. When it lands, this is what lets Python pass it.

[bfrancojr]

CI at a0957a2: all 18 checks pass (Linux, macOS and Windows on py3.10–3.13, the three cibuildwheel builds, CodeQL).