poll-in-obsidian
Node-side “kick off, then poll” helper over evalInObsidian.
A single evalInObsidian closure cannot run longer than the transport’s per-eval cap — DEFAULT_EVAL_CAP_IN_MILLISECONDS (30s) on both, one shared declared number rather than an inherited one: desktop enforces it as commandTimeoutInMilliseconds, Android as scriptTimeoutInMilliseconds, which it also sends as its W3C timeouts.script capability. Either way an overrun is reported as EvalCapExceededError, which names the cap and points here. So a long-running in-Obsidian operation (e.g. a whole plugin/vault bootstrap) cannot be awaited inside one closure. This helper does it from Node instead: it optionally runs a short start closure once to kick the work off, then repeatedly runs a short poll closure — each a separate, well-under-30s eval — until the Node-side until predicate accepts a poll result, or a Node-side timeout elapses. It removes the per-test hand-rolled evalInObsidian + sleep loop.
The timing loop lives in the pure, unit-tested pollUntil; this module is the integration-only wiring (it drives a live Obsidian), covered by an integration test.
Interfaces
Section titled “Interfaces”| Interface | Description |
|---|---|
| PollInObsidianParams | Parameters for pollInObsidian. Mirrors EvalInObsidianParams for the shared forwarded fields (input / contextId / transport / vaultPath); start / poll are the in-Obsidian closures and until is the Node-side acceptance predicate. |
Functions
Section titled “Functions”| Function | Description |
|---|---|
| pollInObsidian | Kicks off an optional start closure once, then polls poll from Node until until accepts a result or the timeout elapses. |