Description
If you look at https://github.com/ably/spaces/blob/main/src/Cursors.ts#L82-L91, you will see that the function a) checks the the user is present, b) adds the cursor position to a queue to be published.
Given the reality is we do have an underlying additional channel for cursors, and that channel state needs to be managed, not providing feedback on whether the message can be published or not leads to bugs such as #339, but more importantly does not provide feedback to the user should there be a terminal issue. So, if for example, the channel was never attached, the user could continue to emit these cursor positions indefinitely without knowing.
Hiding the fact that this depends on a working channel existing is not giving users an API they can depend on. I think we can do better by ensuring the channel is working and receiving messages, and ensuring we raise exceptions if appropriate.
Note that I believe this API is designed to be lower QoS than traditional publish APIs. That is, if you publish 20 cursor updates, we don't need to guarantee all 20 are submitted as we will intentionally batch and conflate as appropriate to ensure both a good user experience and appropriate data rate. However, that does not mean that we can discard all 20 updates, and this API design allows the latter without the user knowing. In short, lower QoS does not mean tolerate any failure unconditionally.