mirror of
https://github.com/meshcore-dev/meshcore_py.git
synced 2026-08-01 20:56:12 +00:00
agessaman
00135bbb95
Two overlapping write_gatt_char() calls on the same characteristic drop the BLE link outright. Observed on macOS/CoreBluetooth as "BLE write failed: 19", after which the connection is gone and the pending command never completes. Nothing above the transport guaranteed callers were sequential: schedulers, health checks, periodic status queries and user commands all issue commands independently, so any unlucky overlap could take the radio down. The existing _mesh_request_lock only guards a few binary-request helpers, not the transport. Reproduced on a companion radio over BLE by issuing send_device_query() and send_node_discover_req() concurrently: before: BLE write failed: 19, connected=False, command hung >45s after: both complete in 0.12s, connected=True Issued sequentially the same two commands take 0.09s each and are fine, so it is specifically the overlap. Ruled out as causes beforehand: notification load (three discovers under a 91-packet firehose kept writes at 0.06-0.17s with the link stable) and the discover command itself. The lock is created lazily so it binds to the running loop, and is released on the failure path so one failed write cannot wedge every later command.
MeshCore Tests
Running Tests
To run the tests, first install the development dependencies:
pip install -e ".[dev]"
Then run the tests using pytest:
# Run all tests
pytest
# Run tests with verbose output
pytest -v
# Run a specific test file
pytest tests/unit/test_commands.py
# Run a specific test
pytest tests/unit/test_commands.py::test_send_msg