- before we fetched pull generation and last_change_id from the remote during pull - which is incorrect because fetched information can be inconsistent with WAL updates we received from the server (latest server state can be in "future" compared to the WAL updates we got since we can make push in parallel with updates pull operation)
- now we read information about "server state" (pull generation, last_change_id) directly from the local DB right after we applied changes from the remote which get us consistent view on the state considering WAL updates we got
- also fetching remote in the pull is bad - since pull block writes and network call with unpredictable latency poorly affect writes to the database
The `run_once()` name is just a historical accident. Furthermore, it now
started to appear elsewhere as well, so let's just call it IO::step() as we
should have from the beginning.
This PR introduces separate `package.browser.json` file for `*-browser`
npm packages (`@tursodatabase/sync-browser` and
`@tursodatabase/database-browser`).
The packages are nearly identical and the only change is `package.json`
content (browser package mentions only WASM optional dependency which
shouldn't confuse NPM and force it to download WASM dep package instead
of native one).
Due to that, innocent "hack" is implemented which swap `package.json`
with `package.browser.json` before publish of `browser` package.
Closes#2906
Using `usize` to compute file offsets caps us at ~16GB on 32-bit
systems. For example, with 4 KiB pages we can only address up to 1048576
pages; attempting the next page overflows a 32-bit usize and can wrap
the write offset, corrupting data. Switching our I/O APIs and offset
math to u64 avoids this overflow on 32-bit targets
Closes#2791
