fix: premature channels state consumption in ChannelManager

[isekovanic]

CLA

• I have signed the Stream CLA (required).
• Code changes are tested

Description of the changes, What, Why and How?

There was an unfortunate bug with the pagination logic in the new ChannelManager that somehow evaded me in the last PR. The offset was not being calculated properly, particularly in cases where:

• We might have state.channels receive updates from something other than pagination (WS events for instance) and it will then contain either broken pagination or duplicate values when actually paginating (for example if a WS event arrives as the query is being executed)
• The state might also change since there's nothing from preventing it (setChannels is public)
• Any other case really between 2 loadNext() invocations

For this purpose, when running the queries we always calculate the offset through state.channels.length and we make sure to run state.getLatestValue() as late as possible, particularly when there are HTTP calls involved (we can ignore the other instances of this happening).

In addition to fixing loadNext(), the relevant WS event handlers have also been fixed (ones that run asynchronously) to make sure the most up to date state is always there.

Changelog

[github-actions]

Size Change: +884 B (+0.17%)

Total Size: 524 kB

Filename	Size	Change
dist/browser.es.js	115 kB	+200 B (+0.17%)
dist/browser.full-bundle.min.js	62.7 kB	+90 B (+0.14%)
dist/browser.js	116 kB	+196 B (+0.17%)
dist/index.es.js	115 kB	+203 B (+0.18%)
dist/index.js	116 kB	+195 B (+0.17%)

_{compressed-size-action}

[isekovanic]

This also makes it evident that offset is pretty much never going to be correct as state.channels gets populated from various WS events. In my eyes, we have 2 options:

• We ignore this and only really use it as a reference pointer to what the last offset was since we anyway calculate the correct one before each query
• We can add an update to offset on every setChannels invocation (a simple size calculation) and then have it be a lot more reliable
  • This naturally won't shield us from all such instances (for example, state.partialNext() or state.next() are very much still a thing) but it should make things more reliable

Thoughts ?

[isekovanic]

Not the same implementation as in lodash obviously and it does not use their fast SetCache, but close enough for such small lists. Still ~ O(n).