Repository navigation
Correct the checkpoint request timeout note - #738
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| Creating the request has no timeout of its own, so it can stay suspended while the sync client retries its connection. Cancel the calling task if you need to stop waiting. | ||
| While the sync client retries its connection, the call waits without a timeout. Cancel the calling task if you need to stop waiting. | ||
|
|
||
| After the request reaches the Service, whether it can time out depends on the client SDK and its HTTP client. If the request times out, `requestCheckpoint()` fails with an error. Call it again to retry. |
There was a problem hiding this comment.
This generalizes a JS/Node-only change to every platform shown on this page. The source PR (powersync-js#1173) adds connectTimeoutMs only to @powersync/common/shared-internals (covering the JS/Web/React Native/Node/Capacitor SDKs). It doesn't touch the Tauri, Dart, Kotlin, Swift, .NET, or Rust SDKs whose examples appear just above this paragraph, so there's no verified basis for claiming their timeout behavior now "depends on the client SDK and its HTTP client" rather than having none. Either scope this sentence to the SDKs where the change actually landed, or verify (and ideally note) each other platform's underlying HTTP client timeout behavior before asserting it generally.
There was a problem hiding this comment.
Except for Dart and Rust SDKs, each SDK has its own timeout, which is why I generalized the claim. I didn't want to make a list, as I think it's not the place for it.
|
Reviewed the diff against the writing standards. One finding posted inline; no other issues found. |
| `requestCheckpoint()` requires that the database is connected or connecting. The device must be online for the request to reach the PowerSync Service. If it is offline or the sync client is reconnecting, the call waits and continues once the Service is reachable. | ||
|
|
||
| Creating the request has no timeout of its own, so it can stay suspended while the sync client retries its connection. Cancel the calling task if you need to stop waiting. | ||
| While the sync client retries its connection, the call waits without a timeout. Cancel the calling task if you need to stop waiting. |
There was a problem hiding this comment.
While the sync client retries its connection, the call waits without a timeout. seems like a duplicate of the previous sentence If it is offline or the sync client is reconnecting, the call waits and continues once the Service is reachable.? We can just add Cancel the calling task if you need to stop waiting. to the previous paragraph?
There was a problem hiding this comment.
That's true. I have changed it and used the word timeout in the first paragraph.
Co-authored-by: benitav <benitav@users.noreply.github.com>
…requirements and timeout behavior
This PR rewords the checkpoint request timeout note after powersync-ja/powersync-js#1173 was merged. Whether the request times out now depends on the client SDK and its HTTP client, instead of "no timeout".
Fixes #732
Claude code was used to double-check the correctness of the claim across SDKs