Environment
- obsidian-headless: v0.0.7
- Node.js: v22.x
- OS: macOS (Apple Silicon)
Description
Every ob sync prints this warning:
(node:56099) TimeoutNaNWarning: NaN is not a number.
Timeout duration was set to 1.
Nothing actually breaks. Node just coerces NaN to 1ms and carries on, but it shows up on every sync for every vault, making it look like something's wrong.
Root Cause
In requestSync(), there's a throttle delay between sync iterations that's calculated from this.server.lastNetworkRequestTs:
if (this.server) {
let i = Date.now() - this.server.lastNetworkRequestTs;
t = Math.max(0, 50 - i);
}
await Yi(t); // Yi = (s) => new Promise(e => setTimeout(e, s))
lastNetworkRequestTs is only assigned inside pull() and push() — it's never initialized in the Ee server class constructor. On the first _sync() iteration, when there are new server files to process, many code paths return true (meaning "keep looping") without ever calling pull() or push().
For example, filtered files, hash matches, folder operations, or illegal filenames all return y(!0) early. So requestSync re-enters the throttle calculation before any network request has happened, and lastNetworkRequestTs is still undefined:
Date.now() - undefined → NaN
Math.max(0, 50 - NaN) → NaN
setTimeout(resolve, NaN) → TimeoutNaNWarning
Stack trace
(node:58547) TimeoutNaNWarning: NaN is not a number.
Timeout duration was set to 1.
at new Timeout (node:internal/timers:199:17)
at setTimeout (node:timers:117:19)
at /opt/homebrew/lib/node_modules/obsidian-headless/cli.js:7:13169
at new Promise (<anonymous>)
at Yi (/opt/homebrew/lib/node_modules/obsidian-headless/cli.js:7:13154)
at Te.requestSync (/opt/homebrew/lib/node_modules/obsidian-headless/cli.js:7:16083)
at async Te.sync (/opt/homebrew/lib/node_modules/obsidian-headless/cli.js:7:15372)
at async Command.<anonymous> (/opt/homebrew/lib/node_modules/obsidian-headless/cli.js:15:128)
Suggested Fix
Either initialize lastNetworkRequestTs in the Ee constructor, or guard the calculation:
// Option A: guard at usage site
let i = Date.now() - (this.server.lastNetworkRequestTs || Date.now());
// Option B: initialize in constructor
this.lastNetworkRequestTs = Date.now();
Option A gives i = 0 → t = 50 (a reasonable 50ms delay on first sync). I've tested this locally, and the warning goes away with no change in sync behavior.
Reproduction
ob sync --path /path/to/any/vault
# Warning appears right after "Connection successful. Detecting changes..."
Shows up on every sync start, for every vault. Running with NODE_OPTIONS="--trace-warnings" gives the full stack trace above.
Environment
Description
Every
ob syncprints this warning:Nothing actually breaks. Node just coerces
NaNto1msand carries on, but it shows up on every sync for every vault, making it look like something's wrong.Root Cause
In
requestSync(), there's a throttle delay between sync iterations that's calculated fromthis.server.lastNetworkRequestTs:lastNetworkRequestTsis only assigned insidepull()andpush()— it's never initialized in theEeserver class constructor. On the first_sync()iteration, when there are new server files to process, many code paths returntrue(meaning "keep looping") without ever callingpull()orpush().For example, filtered files, hash matches, folder operations, or illegal filenames all
return y(!0)early. SorequestSyncre-enters the throttle calculation before any network request has happened, andlastNetworkRequestTsis stillundefined:Stack trace
Suggested Fix
Either initialize
lastNetworkRequestTsin theEeconstructor, or guard the calculation:Option A gives
i = 0→t = 50(a reasonable 50ms delay on first sync). I've tested this locally, and the warning goes away with no change in sync behavior.Reproduction
ob sync --path /path/to/any/vault # Warning appears right after "Connection successful. Detecting changes..."Shows up on every sync start, for every vault. Running with
NODE_OPTIONS="--trace-warnings"gives the full stack trace above.