Affected version and environment
lark-oapi 1.7.3
- Default branch commit:
0b9e6e48b74bb4b34462fc67b7e738b27e73e697
- Windows 11
- Python 3.13.13 and 3.14.4
Problem
The repository's native pytest run has one deterministic Windows-only failure:
FAILED lark_oapi/channel/tests/test_upload_error_propagation.py::
test_gather_buffer_missing_local_file_raises_upload_failed
assert nonexistent in str(err)
gather_buffer() intentionally formats the path with {source.path!r}. On Windows, repr() doubles backslashes, so the raw nonexistent string is not a substring of the rendered exception even though the correct path is preserved in err.context["path"] and as the OSError cause.
Reproduction
From a Windows checkout with test extras installed:
python -m pytest -q -p no:cacheprovider
Observed on both tested interpreters:
- Python 3.13.13:
657 passed, 1 failed
- Python 3.14.4:
657 passed, 1 failed
The failure is at lark_oapi/channel/tests/test_upload_error_propagation.py:37; the formatting under test is at lark_oapi/channel/outbound/media/uploader.py:163.
A minimal equivalent is:
path = r"C:\tmp\does_not_exist.png"
message = f"could not read local file {path!r}"
assert path in message # fails because message contains escaped backslashes
Expected behavior
The native test suite should pass on a supported Windows/Python environment while still checking the useful diagnostic contract.
Suggested fix
Make the assertion representation-aware (for example, assert repr(nonexistent) in the message) and retain the existing exact context assertion, which already proves that callers receive the original path value.
I searched open and closed issues, all pull request states, and repository history for the test name, upload failed, Windows path escaping, and does_not_exist.png. I found no existing report or competing fix; the old Windows path issue #1 and PR #2 concern API URL joining, not exception-message representation.
Affected version and environment
lark-oapi1.7.30b9e6e48b74bb4b34462fc67b7e738b27e73e697Problem
The repository's native pytest run has one deterministic Windows-only failure:
gather_buffer()intentionally formats the path with{source.path!r}. On Windows,repr()doubles backslashes, so the rawnonexistentstring is not a substring of the rendered exception even though the correct path is preserved inerr.context["path"]and as theOSErrorcause.Reproduction
From a Windows checkout with test extras installed:
Observed on both tested interpreters:
657 passed, 1 failed657 passed, 1 failedThe failure is at
lark_oapi/channel/tests/test_upload_error_propagation.py:37; the formatting under test is atlark_oapi/channel/outbound/media/uploader.py:163.A minimal equivalent is:
Expected behavior
The native test suite should pass on a supported Windows/Python environment while still checking the useful diagnostic contract.
Suggested fix
Make the assertion representation-aware (for example, assert
repr(nonexistent)in the message) and retain the existing exact context assertion, which already proves that callers receive the original path value.I searched open and closed issues, all pull request states, and repository history for the test name,
upload failed, Windows path escaping, anddoes_not_exist.png. I found no existing report or competing fix; the old Windows path issue #1 and PR #2 concern API URL joining, not exception-message representation.