How do clients know if a descriptor is new/changed/or disappeared from the Tor network?

Question

I noticed a paragraph in dir-spec.txt as follow:

To address these, we extended the directory protocol so that
authorities now published signed "network status" documents. Each
network status listed, for every router in the network: a hash of its identity key, a hash of its most recent descriptor, and a summary of what the authority believed about its status. Clients would download the authorities' network status documents in turn, and believe statements about routers iff they were attested to by more than half of the authorities.

Instead of downloading all server descriptors at once, clients
downloaded only the descriptors that they did not have. Descriptors were indexed by their digests, in order to prevent malicious caches from giving different versions of a server descriptor to different clients.

So could anyone please explain me how Tor clients check if a descriptor is there in their recent network-status-document? If the answer is basing on "what I have highlighted", could anyone please give me a hint where I can have a look at those "variables", given that the recent version of Tor only fetchs micro-descriptors, not the whole server-descriptors. Thank you so much!

____Edit______ So from this Snapshot (please copy URL of the image and open it in new-tab for a better view), I compared two cached-microdesc-consensuses at two different time, and the differences are highlighted by the plugin of Notepad++. As you can see the "identity key hash" and the hash of its most recent descriptor did not change. So can you please tell me a little bit more details of how a client update microdesc-consensuses? Say,

1. will they send the "identity key hash" OR/AND the hash of its most recent descriptor of all descriptors to Directory Mirrors,
2. then the mirrors will check if any value of those descriptors has changed
3. next,the mirrors reply to client by sending only those descriptors that have been changed?

Answer 1

Tor maintains a descriptor store which keeps all the descriptors it knows about. New descriptors enter the store after being downloaded, old descriptors get expired when they haven't been referenced and are outdated. The client regularly fetches a new consensus document and fetches all the descriptors that it doesn't have and that are referenced in the consensus. This process is the same for microdescriptors or regular descriptors - there is a different type of consensus document for each, either referencing microdescriptors or regular descriptors.

edit
As for the terms that you have asked about, let's use an example from a microdescriptor consensus:

r comptor4 AAhWy/I+9s3Ndx9O/wOEJEcL7G0 2015-03-11 02:52:31 106.185.37.52 443 80
The "AAhWy/I+9s3Ndx9O/wOEJEcL7G0" is the identity key hash.

m kJecYrKO9FCZz7vElqiTmO2n6qCBZ3+C3/LHRtcdIME
The "kJecYrKO9FCZz7vElqiTmO2n6qCBZ3+C3/LHRtcdIME" is the hash of its most recent descriptor

s Fast HSDir Running V2Dir Valid
The things after the s are the flags for this relay.

v Tor 0.2.4.24
The Tor version

w Bandwidth=20 Unmeasured=1
How fast this relay is

The identity key is not included in the microdescriptor consensus, because that would be redundant. Hashing it makes it shorter and is sufficient for our purposes.

To calculate the hash of the most recent descriptor, the entire microdescriptor that was calculated for the relay is hashed, and that hash value stored into the consensus to allow a reference to it. That way, the client can check if it knows about the microdescriptor because it memorizes the list of microdescriptors it knows about as well as their hashes.