Refuses the verification, or abandons it, and queues the refusal for the
pump.
The call a product must be able to make at any point a person can look
at a screen and say "that is not what I see". Refusing is not a failure
of this library; a comparison that can only ever agree proves nothing.
Cancels the comparison if one has started, the scannable code if the flow
became one, and the invitation otherwise. The first two also cancel the
invitation behind them. Nothing is verified, on either side.
Rejects with 'wrong_stage' for a flow that was already cancelled.
"Already refused" and "refused by this call" are the same outcome, but a
caller told Ok for a cancellation it did not perform has been told
something false.
Skipping this does not fail silently, but it does fail slowly. A flow
nobody cancels sits open until the protocol's own ten-minute timeout
retires it.
The one screen this is the only way off
A flow that reaches 'code-scanned' is waiting for a person to answer
confirmScan, and some clients will already have declared
themselves finished by then. When that happens the flow never moves again:
the stage stays 'code-scanned' however long you pump, and
confirmScan cannot end it because the other side has stopped
listening.
This is the call that ends it, and it matters more than it looks. A
verification left in that state is still live as far as the layer
underneath is concerned, and it allows one live verification per person,
so it takes the next two attempts with that person down with it. Those two
die quietly: no rejection, no error, just a flow that reads 'cancelled'
from the start. Cancel the stuck one, sync once (see
requestVerification for why), and the next verification with that
person behaves normally.
A product that shows a code should therefore offer a way out of that
screen rather than only a way forward, and call this when a person takes
it.
Refuses the verification, or abandons it, and queues the refusal for the pump.
The call a product must be able to make at any point a person can look at a screen and say "that is not what I see". Refusing is not a failure of this library; a comparison that can only ever agree proves nothing.
Cancels the comparison if one has started, the scannable code if the flow became one, and the invitation otherwise. The first two also cancel the invitation behind them. Nothing is verified, on either side.
Rejects with
'wrong_stage'for a flow that was already cancelled. "Already refused" and "refused by this call" are the same outcome, but a caller toldOkfor a cancellation it did not perform has been told something false.Skipping this does not fail silently, but it does fail slowly. A flow nobody cancels sits open until the protocol's own ten-minute timeout retires it.
The one screen this is the only way off
A flow that reaches
'code-scanned'is waiting for a person to answer confirmScan, and some clients will already have declared themselves finished by then. When that happens the flow never moves again: the stage stays'code-scanned'however long you pump, and confirmScan cannot end it because the other side has stopped listening.This is the call that ends it, and it matters more than it looks. A verification left in that state is still live as far as the layer underneath is concerned, and it allows one live verification per person, so it takes the next two attempts with that person down with it. Those two die quietly: no rejection, no error, just a flow that reads
'cancelled'from the start. Cancel the stuck one, sync once (see requestVerification for why), and the next verification with that person behaves normally.A product that shows a code should therefore offer a way out of that screen rather than only a way forward, and call this when a person takes it.