new phone who dis #335
Comments
|
cc @phritz . I'm not sure what the priority of this should be, but it does happen quite frequently. Probably will happen to almost every user at some point during development. |
|
I am not sure if the right thing is for the client to always interpret this particular condition as it should start over, or if it should be an explicit action of some type that the server takes to tell clients to nuke themselves. |
|
I wanna explore what we expect to happen in the following cases.
seems like generally we can detect old clients who should be nuked so long as they have pushed at least one mutation. i'm not sure if it is important to be able to detect old clients who should be nuked who have not pushed a mutation. regarding wether the client should detect or server signal for it to nuke itself. i suspect we probably want a signal from the server to the client to nuke itself so the server can correct its mistakes. as for the reset itself, it seems like the app should drive the reset of repc because the app is also going to have to do its own reset/bookkeeping. to reset repc do we... drop the database? if so what happens to stuff that is mid-flight in another tab? or if one tab comes to life after another resets, can it detect that gracefully and cause its app instance to reset? what's required to reset the bindings -- do we tear everything down and start completely over eg with registering mutations etc? |
…ing bootstraping from existing client state. (#712) Simplified Dueling Dags always creates a new Client for each new tab. To enable fast startup of new tabs utilizing previous stored data Simplified Dueling Dags bootstraps new clients by forking an existing Client's state. When forking from another Client, the fork should be based on the existing Client's most recent base snapshot (which may not be its latest head). This is necessary because pending mutations (LocalMutationCommits) cannot be forked as the last mutation id series is different per client. It is important that the last mutation id for the new client be set to 0, since a replicache server implementation will start clients for which they do not have a last mutation id stored at last mutation id 0. If the server receives a request from a client with a non-0 last mutation id, for which it does not have a last mutation id stored, it knows that it is unsafe for it to execute mutations form the client, as it could result in re-running mutations or otherwise failing to guarantee sequential execution of mutations. This tells the server that this is an old client that it has GC'd (we need some way to signal this to the client so it can reset itself, see #335). When choosing a Client to bootstrap from, it is safe to pick any Client, but it is ideal to chose the Client with the most recent snapshot from the server. Currently the age of snapshots is not stored, so this implementation uses a heuristic of choosing the base snapshot of the Client with the newest heartbeat timestamp. See larger design at https://www.notion.so/Simplified-DD1-1ed242a8c1094d9ca3734c46d65ffce4#64e4299105dd490a9ffbc6c9c771f5d2 Part of #671
ProposalExpand type PullResponseOK = {
cookie?: ReadonlyJSONValue;
lastMutationID: number;
patch: PatchOperation[];
};
type ClientStateNotFoundResponse = {clientStateNotFound: true};
type PullResponse = PullResponse | ClientStateNotFoundResponse;When we get a |
|
How about:
error: {
type: “ClientStateNotFound”
}
In case we come up with other kinds of errors or want to add additional
information to the errors?
On Fri, Mar 18, 2022 at 3:42 AM Erik Arvidsson ***@***.***> wrote:
Proposal
Expand PullResponse to be something like:
type PullResponseOK = {
cookie?: ReadonlyJSONValue;
lastMutationID: number;
patch: PatchOperation[];};
type ClientStateNotFoundResponse = {clientStateNotFound: true};
type PullResponse = PullResponse | ClientStateNotFoundResponse;
When we get a ClientStateNotFoundResponse we call onClientStateNotFound
(yes, we reuse the existing callback)
—
Reply to this email directly, view it on GitHub
<#335 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAATUBBRZHGRA6YRFPHID53VARM2ZANCNFSM4ZZ6TCFQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
a (phone)
|
The server can now tell the client that it does not know about a client.
When this happens the client calls `onClientStateNotFound`.
The server can return:
```json
{"error": "ClientStateNotFound"}
```
Fixes #335
The server can now tell the client that it does not know about a client.
When this happens the client calls `onClientStateNotFound`.
The server can return:
```json
{"error": "ClientStateNotFound"}
```
Fixes #335
The server can now tell the client that it does not know about a client.
When this happens the client calls `onClientStateNotFound`.
The server can return:
```json
{"error": "ClientStateNotFound"}
```
Fixes #335
The server can now tell the client that it does not know about a client.
When this happens the client calls `onClientStateNotFound`.
The server can return:
```json
{"error": "ClientStateNotFound"}
```
Fixes #335
It is frequently the case, especially during development, but occasionally in production too, that a server just wants to drop a particular client's state. Just... forget it. rm -rf, start over.
Unfortunately, when that happens, the client is then wedged. It goes to sync, uses its existing client ID, and the data layer doesn't recognize them.
We need a way for the server and client to negotiate this, and end up with the client getting a fresh state too.
The text was updated successfully, but these errors were encountered: