Updating ARTRealtimeChannel’s options doesn’t update the options of its ARTRestChannelInternal

[lawrence-forooghian]

When calling -[ARTRealtimeChannel setOptions:callback:], the passed options are not used to update the options of this instance’s REST channel. This means that, for example, if we update the realtime channel’s cipher options, these options will not be used to decrypt messages subsequently fetches using the -history:* methods.

I think this is something we missed when doing #1207.

This is causing ably/ably-flutter#296.

┆Issue is synchronized with this Jira Bug by Unito

[QuintinWillison]

I guess the spec (RTL16, Realtime Channel#setOptions) does not explicitly state that the client library should also synchronise this across to the REST side. 🤔

There is, of course, the equivalent method for REST specified by RSL7. And I note that in the IDL there is an obscure note against RestChannel#setOptions:

asynchronous return value for compatibility with RealtimeChannel#setOptions; not required for REST-only libraries

I think there may be room for a spec improvement once this bug has been fixed.

[lawrence-forooghian]

I think that the fact that the realtime class wraps an instance of the REST class is kind of an implementation detail; I don't think that the spec makes this explicit. So I suppose there's no reason to expect it to mention it. Perhaps the spec should however be explicit that the history calls need to make sure they respect cipher params that were passed to the top-level channel (be it realtime or REST). (Perhaps it already is, I've only scanned.)

[QuintinWillison]

FYI, @paddybyers @SimonWoolf - in case you have any thoughts and/or historical context to share around this. Thanks.

[SimonWoolf]

I think that the fact that the realtime class wraps an instance of the REST class is kind of an implementation detail

Yeah, the libs I'm more familiar with don't do this, they have a realtime channel subclass the rest channel. The idea that the spec should state that "the client library should also synchronise this across to the REST side" seems weird to me -- as far as the spec is concerned a channel is a single entity, if a lib wants to implement that with multiple communicating objects that's fine, but it's then its responsibility to not let that affect user-visible behaviour