https://bugs.openldap.org/show_bug.cgi?id=6138

Howard Chu hyc@openldap.org changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1

--- Comment #7 from Howard Chu hyc@openldap.org --- (In reply to Hallvard Furuseth from comment #0)

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard

Might make this a tracking issue for Cancel/Abandon problems. And/or copy some to separate ITSes, but they all seem interconnected:

Cancel(abandoned operation)-requests are not rejected. Thus slapd sets o_cancel and turns an active Abandon into a Cancel. Presumably that can confuse Cancel/Abandon handlers, like that in Syncprov.

Similarly, Abandon(abandoned/cancelled operation) is not ignored. connection_abandon() re-abandons abandoned/cancelled operations too.

Both of the above checks are now uncommented / enabled.

However Syncprov:RefreshAndPersist abuses op->o_abandon: It sets it to mean "Suppress the response. A copy of this operation will send it." So if Cancel(op with o_abandon!=0) is fixed to respond protocolError "already abandoned", presumably that breaks Cancel(RefreshAndPersist).

I'm not touching it with a flagpole - I don't know syncprov. Help?

syncprov has been changed to use the new SLAPD_ASYNCOP returncode so it no longer needs to muck with this.

Overlay retcode does something similar - sends a response and then sets o_abandon.

I can't see any reason why this is needed. It's been there since the initial commit but I'm removing it. Any return code != SLAP_CB_CONTINUE already prevents the frontend from sending its own response so there's no reason to set this here.

Cancel/Abandon can in any case fail by targeting the wrong operation though: A connection can have multiple messages with the same IDs when the response is sent and the client reuses the message ID, before the old operation in slapd can clean up and finish.

syncprov_op_abandon() identifies messages by (connid, msgid). Can multiple messages with the same ID break that, or more importantly, break what gets sent/written with syncrepl?

Sounds like bad practice in clients, but should still be safe. The messages are queued in order, so only the first matching message will be abandoned. Presumably the first incoming abandon request can only refer to the first queued operation of that ID.

Anyway, the current code needs an o_abandon value which means "suppress response". Or maybe "abandoned, except as far as future Abandon and Cancel operations are concerned". Syncprov and Retcode need to handle the various possible orderings of Cancel/Abandon vs Suppress, including when they forward o_abandon from one operation to another. I haven't looked too closely at that code either.

Mooted by use of SLAPD_ASYNCOP returncode.