Can we replace FETCH_CANCEL with STOP_SENDING?

[afrind]

A subscriber issues a FETCH_CANCEL message to a publisher indicating it is no longer interested in receiving Objects for the fetch specified by 'Subscribe ID'. The publisher SHOULD close the unidirectional stream as soon as possible.

One reason I can see for FETCH_CANCEL to be separate is so it can be issued before receiving the FETCH stream.

[suhasHere]

One thing i liked about fetch_cancel is , it provides an nice application API.
Curious to understand what might be the downside of having it.

[afrind]

Individual Comment:

One thing i liked about fetch_cancel is , it provides an nice application API.

Nothing really changes about your application API if we change the wire signal from FETCH_CANCEL to STOP_SENDING.

Curious to understand what might be the downside of having it.

The downside is there are edge cases with FETCH_CANCEL that don't exist with STOP_SENDING -

1. cancelling a fetch with an invalid subscribe ID
2. fetch already closed
3. cancelling a fetch before the fetch OK -- though as mentioned in the OP, this problem moves to the client side.

Victor suggested using a bidi stream for FETCH and its response on #632 which mitigates these, but would introduce (solvable) problems with control message ordering.

[ianswett]

There are a number of ways to do this and I don't have a strong opinion. Putting FETCH on a single bidi stream seems sensible, and I'm unsure if there are any downsides?

[afrind]

Individual Comment

I'm unsure if there are any downsides?

The primary downside is that it can create ordering problems, for example see #638 where the FETCH needs to follow
the SUBSCRIBE. I recall this was discussed in Boston. This is tractable but does need to be addressed.

[afrind]

Individual Comment:

Another reason to prefer bidirectional streams is that the sender of the FETCH is guaranteed to have an allocated return path for the data. If we use control+unidirectional stream, there's a case where the publisher is out of stream credit to reply.

[martinduke]

Relatedly, do we need FETCH_DONE in case the publisher wants to terminate it before the stream exists (perhaps due to a lack of stream credit?) Or is FETCH_OK a commitment to open the stream?

[afrind]

I'm now inclined to leave this as is, maybe with editorial clarification around the edge cases. Once the data stream is open, I would expect FETCH_CANCEL and STOP_SENDING to be handled equivalently by the publisher, so sending both is redundant, but basically free.

I don't think moving FETCH to a bidi stream is solving more problems than it creates, and FETCH_CANCEL is basically fine.

[afrind]

Related question - does a publisher need to send FETCH_ERROR if it receives a FETCH_CANCEL or STOP_SENDING before sending FETCH_OK/_ERROR?

[martinduke]

@afrind has decided the status quo is fine.