#24 lists a courtesy notification among revocation's rules: a revoking server
attempts to tell the peer, and the attempt failing affects nothing, because a
revocation that depends on reaching the peer is not a revocation. Its four done
conditions do not cover it, and with the revocation itself built and #24 closed,
that half is claimed by nothing:
gh issue list --repo Flowfin/jellyfin-plugin-server-pairing --state all --limit 400 --json number,title,body --jq '.[]|select((.title+.body)|test("courtesy notification";"i"))|"\(.number) \(.title)"'
24 Make revocation unilateral, immediate and terminal
One issue names it, and it is the one that stops here. So this issue takes it,
rather than leaving it in a closed body where the next reader has to work out
that nobody is holding it.
What holds it
Two fields a message this server sends cannot be built without, and neither is on
the record:
git grep -nE 'Version|Address' origin/master -- Jellyfin.Plugin.ServerPairing/Protocol/PairingRecord.cs ; echo "exit=$?"
exit=1
Empty output and exit one. The peer address is claimed by #18 in its own body and
the selected version by #316, so this waits on both rather than on an answer
nobody has given.
Revoke is already a wire message, so nothing new is owed on the protocol
itself:
git grep -n '^ Revoke = ' origin/master -- Jellyfin.Plugin.ServerPairing/Protocol/PairingMessage.cs
origin/master:Jellyfin.Plugin.ServerPairing/Protocol/PairingMessage.cs:35: Revoke = 3,
What it must not become
The failure this is written against is a revocation that waits. Revocation is
built from two stores and nothing that could reach a peer, and a case asserts
that shape, so whatever attempts the notification is a second act that follows a
completed revocation rather than a third argument to it. A design that puts a
channel inside the operation reds that case, which is the point of it.
Done when
- a completed revocation attempts one
Revoke message to the peer, read from the
record rather than from anything the caller passed
- a test asserts the revocation completes with the same outcome, the same key
destroyed and the same record written when the attempt throws, times out, and
is refused
- a test asserts nothing about the attempt is awaited before the revocation is
reported complete
docs/protocol.md says what the notification is and what a peer does with one,
beside the rule that a peer acts only on a notification it can verify
#24 lists a courtesy notification among revocation's rules: a revoking server
attempts to tell the peer, and the attempt failing affects nothing, because a
revocation that depends on reaching the peer is not a revocation. Its four done
conditions do not cover it, and with the revocation itself built and #24 closed,
that half is claimed by nothing:
One issue names it, and it is the one that stops here. So this issue takes it,
rather than leaving it in a closed body where the next reader has to work out
that nobody is holding it.
What holds it
Two fields a message this server sends cannot be built without, and neither is on
the record:
Empty output and exit one. The peer address is claimed by #18 in its own body and
the selected version by #316, so this waits on both rather than on an answer
nobody has given.
Revokeis already a wire message, so nothing new is owed on the protocolitself:
What it must not become
The failure this is written against is a revocation that waits.
Revocationisbuilt from two stores and nothing that could reach a peer, and a case asserts
that shape, so whatever attempts the notification is a second act that follows a
completed revocation rather than a third argument to it. A design that puts a
channel inside the operation reds that case, which is the point of it.
Done when
Revokemessage to the peer, read from therecord rather than from anything the caller passed
destroyed and the same record written when the attempt throws, times out, and
is refused
reported complete
docs/protocol.mdsays what the notification is and what a peer does with one,beside the rule that a peer acts only on a notification it can verify