What is now true of the objects a client names, or of an area it names

Answers what the journal cannot: what a client still sees, after a position it can no longer read from and after a boundary of visibility moved.

The method has two modes and the request chooses between them by what it carries. Name objectIds to ask about the objects the memory of the client already holds. Name scopeRootId to ask about an area - the root a change of access named. A request that names both is refused, and so is one that names neither: guessing which was meant would answer a question that was not asked.

Over a list the answer holds exactly one item per object, in the order the objects were asked about. Over an area the answer is a page: ask for the next one with the nextCheckToken of the previous, and stop when hasMore says the area is over. A page that came back short is not the end of it - links inside an area collapse onto the object they point at - and only hasMore answers that question.

An object the caller does not see is answered visible: false and carries no card. That answer is the same for an object hidden from the caller and for an object that was never there: the method never asks whether an object exists, so it cannot be used to find out. For the same reason an area whose root the caller cannot see is answered with an empty finished page rather than with a refusal - which is the ordinary case, not an edge one: the first move of a reconciliation runs right after a revocation, when the root is already invisible.

An area whose root is perfectly visible answers the same way when everything in it changed too recently, and a client that reads an empty finished page as an empty area loses those objects for good. A page is read against a boundary of state standing a little behind the current instant, and what changed above that boundary enters no page of the walk. So an empty finished first move does not mean an empty area: repeat the first move on the next step of polling before treating the area as walked through. safeWindowSeconds is not that boundary - it describes the journal and the initial fetch, while a walk over an area is read against a narrower one of its own.

A visible object may arrive without a card. It was deleted between the verdict that named it and the assembly that describes it; the client reads it back and waits for the journal to say otherwise, rather than dropping an object it has just been told it can see.

The check answers about the state of right now. No depth of history is applied to it - bounded by depth it would say "you do not see it" about a visible object that simply had not changed for a long time - and objects in the trashcan are visible objects like any other. The consequence is accepted: after a check the memory of a client may hold objects older than the depth its session was given.

The check moves no cursor, reads no journal and neither needs a session nor touches one. checkToken is its own kind of position with a boundary of state and a life of its own, and an expired one is refused with CHECK_TOKEN_EXPIRED - a code of its own, so that a client does not go and recreate a session the check never used. A token of another user, of another application of the same user, of another kind or damaged in any way is refused with CURSOR_INVALID.