Describe the bug
LocalSynchronizer uses a fixed 10 ms request timeout, while both the request and response are delivered through timers. On this Windows/Node environment, normal local request-response exchanges can expire before the response arrives. This can leave stores divergent even when the receiving peer has correctly applied a change.
Steps to Reproduce
With two local synchronizers, apply middleware on the receiving store that uppercases incoming string values. Start synchronization, then write a to the origin. The receiver becomes A but the origin remains a. The ignored-error callback records tinybase:3 for GetValueDiff requests. The receiver's outgoing response contains A with its newer stamp; an explicit save still times out on the return exchange.
The existing middleware-transformed data syncs back to originator and middleware-transformed value syncs back to originator tests reproduce this on the current main build.
A deterministic regression also reproduces it without middleware: use fake timers to deliver zero-delay local callbacks after 15 ms, leave the request timeout unchanged, and load from an auto-saving peer with a prepopulated value. The load completes without importing the value. With the internal deadline restored to 50 ms, the same test imports it with no ignored errors.
Expected behavior
Local peers should have sufficient time for a timer-scheduled request and response to complete. Normal local synchronization should not silently lose an exchange due to the 10 ms deadline.
Platform
- Windows, Node.js v24.14.1
- Main
f09e5a3b74ea16b6fac93439be34cc3f954f1e7c, package version 9.7.0
Additional context
Commit 4be22f647658dd203844f28842c762783f86bc49 reduced the deadline from 50 ms to 10 ms as part of test timing changes. Restoring 50 ms fixes the reproduced scenarios without changing the public API. The tradeoff is a longer wait when no peer responds; it is not a guarantee against arbitrary event-loop stalls.
Describe the bug
LocalSynchronizer uses a fixed 10 ms request timeout, while both the request and response are delivered through timers. On this Windows/Node environment, normal local request-response exchanges can expire before the response arrives. This can leave stores divergent even when the receiving peer has correctly applied a change.
Steps to Reproduce
With two local synchronizers, apply middleware on the receiving store that uppercases incoming string values. Start synchronization, then write
ato the origin. The receiver becomesAbut the origin remainsa. The ignored-error callback recordstinybase:3for GetValueDiff requests. The receiver's outgoing response containsAwith its newer stamp; an explicit save still times out on the return exchange.The existing
middleware-transformed data syncs back to originatorandmiddleware-transformed value syncs back to originatortests reproduce this on the current main build.A deterministic regression also reproduces it without middleware: use fake timers to deliver zero-delay local callbacks after 15 ms, leave the request timeout unchanged, and load from an auto-saving peer with a prepopulated value. The load completes without importing the value. With the internal deadline restored to 50 ms, the same test imports it with no ignored errors.
Expected behavior
Local peers should have sufficient time for a timer-scheduled request and response to complete. Normal local synchronization should not silently lose an exchange due to the 10 ms deadline.
Platform
f09e5a3b74ea16b6fac93439be34cc3f954f1e7c, package version 9.7.0Additional context
Commit
4be22f647658dd203844f28842c762783f86bc49reduced the deadline from 50 ms to 10 ms as part of test timing changes. Restoring 50 ms fixes the reproduced scenarios without changing the public API. The tradeoff is a longer wait when no peer responds; it is not a guarantee against arbitrary event-loop stalls.