skip to content

A long-running LDAP operation must be called off — what does an AbandonRequest actually guarantee?

level: seniorimportance: should knowfreq 30%

answer

  1. it names a message, not an entry
  2. silence is the whole protocol
  3. no acknowledgement, no rollback
  4. the client stops listening by itself
  5. closing the connection is the blunt version

basics

~20 s

Very little. An AbandonRequest names the messageID of an outstanding operation and draws no response of any kind, so the client learns nothing about whether the server stopped, had already finished, or ignored it — and nothing is undone.

solid answer

~40 s

`AbandonRequest` carries one thing: the `messageID` of the operation to abandon. It has **no response**, so there is no `resultCode` to read and the client cannot tell whether the server stopped work, had already completed the operation, or declined. The obligations that remain are the client's own: stop waiting on that `messageID` and discard any messages still arriving for it. Crucially, abandoning a write undoes nothing — the change may already have been applied, and the protocol offers no rollback. `UnbindRequest` is the blunt instrument beside it: it also has no response, it is not the opposite of the LDAP Bind operation, and it terminates the connection along with everything outstanding on it.

code

pseudocode · 10 lines
pseudocode
send ModifyRequest(...)  as messageID 14
...
send AbandonRequest(messageID = 14)   -- no reply of any kind follows

stop waiting on messageID 14
discard any message that still arrives carrying messageID 14
do not reuse messageID 14 on this connection

-- the change may already have been applied; nothing here undoes it
-- to learn the entry's state, read it back

go deeper

for a junior

Recall that abandoning names the outstanding message rather than an entry, and that no confirmation comes back for it.

for a middle

Explain the client-side consequences of a request with no response: stop waiting, discard late messages, and do not reuse the message identifier.

for a senior

Show that you design long-running directory work for interruption — idempotent writes, verification by reading back, small units — because abandoning tells you nothing about what landed.

for a principal

Set the expectation across an estate: a write protocol with no cancel and no rollback means reconciliation is a first-class component, not an error path bolted on afterwards.

## The request with no reply `AbandonRequest ::= [APPLICATION 16] MessageID`. The whole body is the `messageID` of an operation the client has already sent. There is no entry name, no reason code, and — the part that surprises people — **no response at all**. A server that honours it sends nothing. A server that has already finished the work sends nothing. A server that declines sends nothing. From the client's side the three are indistinguishable. Abandon cannot itself be abandoned, for the same reason: there is no outstanding operation to name. ## What the client is actually responsible for Because the protocol acknowledges nothing, every remaining obligation is local: 1. **Stop waiting on that `messageID`.** No message will ever arrive to close the loop, so a client that blocks until it hears something blocks forever. 2. **Discard messages that still arrive for it.** Responses already in flight when the abandon was sent will keep arriving, and they are not evidence that the abandon failed. 3. **Never reuse the `messageID` while anything might still be outstanding for it**, or a late message will be attributed to a new operation. ## What it does not do The question an interviewer is really asking is what the client may conclude. The honest answer is **nothing about the entry**: - Abandoning a Modify **does not undo it**. If the server applied the change before the abandon arrived, the change stands. There is no rollback in the operation set. - Abandoning does not guarantee the server stops spending resources; it is a request, and the server decides. - Abandoning does not tell the client how far a long operation got. So a job that may be called off has to be designed for it: make each write idempotent so repeating it is harmless, verify state by reading the entry back rather than by inferring it, and keep the unit of work small enough that "did that land?" is a cheap question to answer. ## Where it earns its place The honest use of Abandon is **resource courtesy**, not control. An operator closes the console in the middle of a long enumeration; a request has already exceeded the client's own deadline; a user navigates away from a page whose lookup is still running. In each case the client no longer wants the results, and telling the server so lets it stop spending on them. What the client must not do is treat the abandon as the end of the story. ## Unbind is not the opposite of Bind `UnbindRequest ::= [APPLICATION 2] NULL` is the other operation with no response, and its name is one of the protocol's worst. It does not undo an LDAP Bind operation and it does not return the connection to an unauthenticated state. It says **the client is finished**, and the connection is terminated — every outstanding operation with it. | | Abandon | Unbind | |---|---|---| | body | the `messageID` to abandon | nothing | | response | none | none | | effect | asks the server to drop one operation | ends the connection entirely | | outstanding work | only the named operation is targeted | all of it goes | | what is undone | nothing | nothing | Dropping the connection is therefore the blunt way to stop everything at once — and it still guarantees nothing about writes already applied. ## The shape of the answer A strong candidate says three things: the request names a message rather than an entry; it has no reply, so the client's own bookkeeping is the whole mechanism; and it is not a cancel, because nothing is rolled back. A weak one describes it as the LDAP equivalent of pressing stop and expects a confirmation to come back.

  • If Abandon gives no feedback, how does a client learn whether the operation took effect?
    Not from the protocol. It reads the entry back and looks, and it designs the write so that repeating it is harmless — an `add (0)` change that may earn `attributeOrValueExists (20)`, or a `replace (2)` to a known target value. Inference from the abandon itself is guesswork.
  • What does Unbind do that Abandon does not?
    It ends the connection, and with it every outstanding operation and the connection's authentication state. Like Abandon it has no response, and despite the name it is not the reverse of an LDAP Bind operation — there is no way to say 'forget who I am but keep the connection' with it.

Abandoning is hanging up on a phone order rather than cancelling it: the shop may already have packed the parcel, and nobody rings back either way to tell you which happened.

saying these in an interview costs you the question

  • Expects a resultCode confirming the operation was abandoned
  • Thinks abandoning a Modify undoes a change already applied
  • Says Unbind is the counterpart of the LDAP Bind operation
  • Assumes the server must stop the moment the request arrives
  • Believes no responses can arrive after the abandon is sent
  • Reuses the messageID immediately after abandoning it