chore: Support x-ld-envid in updates

[keelerm84]

Note

Propagates X-LD-EnvID/FD-Fallback headers through polling/streaming to set Update.environment_id and trigger FDv1 fallback; refactors error/header handling and expands tests, with minor build tweaks.

• Data source v2 (polling/streaming):
  • Use _LD_ENVID_HEADER/_LD_FD_FALLBACK_HEADER to read X-LD-EnvID and FD fallback, attaching environment_id to all Updates and honoring fallback in both success and error paths.
  • Preserve environment_id across stream events; include it in INTERRUPTED/OFF states; handle Start/Fault headers and recoverable/unrecoverable errors consistently.
  • Requesters now pass response headers with failures; parsing failures also return headers.
• Util:
  • Add _LD_ENVID_HEADER/_LD_FD_FALLBACK_HEADER constants.
  • UnsuccessfulResponseException no longer stores headers; _Fail gains optional headers.
• Tests:
  • Extensive new tests for environment_id propagation and FD fallback across polling and streaming scenarios.
  • Update examples to use TestDataV2 builders directly.
• Build/Config:
  • Makefile: ensure .mypy_cache exists before running mypy.
  • Bump pytest to ^8.0.0.

^{Written by Cursor Bugbot for commit 94c2334. This will update automatically on new commits. Configure here.}

[cursor]

Bug: Start Action Leaves Environment State Stale

When a Start action arrives with headers=None, the envid variable isn't updated, causing it to retain a stale value from a previous Fault action. This means subsequent event updates could incorrectly use an environment_id that was only meant for the fault's error update. The condition if isinstance(action, Start) and action.headers is not None: should update envid regardless of whether headers exist, setting it to None when headers are absent to properly reflect the new connection state.

 

[cursor]

Bug: Fault object: Headers in the wrong place.

The code attempts to access action.headers on a Fault object, but Fault objects don't have a headers attribute. The headers are stored on the error object (action.error.headers), as evidenced by the fallback logic in _handle_error at line 354-355 which correctly accesses error.headers. This will cause an AttributeError when a Fault with an error containing headers is encountered.

 

[keelerm84]

This is a good point. Fixed.