Amarula.Connection.PreKeyOps (amarula v0.4.2)
View SourcePure pre-key decision logic for Amarula.Connection (Baileys
uploadPreKeysToServerIfRequired).
The socket-bound parts — sending the count IQ, the upload round-trip, the
tracked-IQ continuations, finish_login — stay on Connection, since they
drive the login lifecycle. What lives here is pure: building the count-query
node, reading the server's count, choosing the upload target, and deciding
whether an upload is needed. No socket, no state; testable directly.
Summary
Functions
The <iq type=get xmlns=encrypt><count/></iq> that asks how many one-time prekeys the server holds.
True when the last-generated one-time prekey is no longer in local storage.
Read the <count value=…> the server returned (defaults to 0 when absent).
Whether to upload, given the server count and our creds. True when the server
pool has dropped to/below the low-water mark, or our most-recently-generated
prekey is gone locally (Baileys verifyCurrentPreKeyExists). target is unused
here (kept for call-site symmetry with upload_target/1).
How many new prekeys to upload for a given server count: enough to restore the
server pool back to initial_pre_key_count (never fewer than min_pre_key_count).
Functions
@spec count_query_node() :: Amarula.Protocol.Binary.Node.t()
The <iq type=get xmlns=encrypt><count/></iq> that asks how many one-time prekeys the server holds.
True when the last-generated one-time prekey is no longer in local storage.
@spec server_count(Amarula.Protocol.Binary.Node.t()) :: non_neg_integer()
Read the <count value=…> the server returned (defaults to 0 when absent).
@spec upload_needed?(non_neg_integer(), pos_integer(), map()) :: boolean()
Whether to upload, given the server count and our creds. True when the server
pool has dropped to/below the low-water mark, or our most-recently-generated
prekey is gone locally (Baileys verifyCurrentPreKeyExists). target is unused
here (kept for call-site symmetry with upload_target/1).
@spec upload_target(non_neg_integer()) :: pos_integer()
How many new prekeys to upload for a given server count: enough to restore the
server pool back to initial_pre_key_count (never fewer than min_pre_key_count).
Baileys only uploaded the deep batch when the server held exactly 0, and topped
up by min (5) otherwise — so the pool idled near-empty and dropped first-contact
messages (#2643). Refilling toward the initial count keeps the pool healthy.