Expected behaviour for repeated subscribe/unsubscribe

I am trying to do a drop-in replacement of an existing but slow synchronous-API call with an async workflow, using Sidekiq on the backend and Message Bus front and back.

The existing front-end code looks roughly like:

getResults(params) {
  return callApi(params); // responds 
}

My attempt to replace it looks like:

lastMessageId = -2;

async getResults(params) {
  const asyncResponsePromise = new Promise((resolve) => {
    // MessageBus.stop(); MessageBus.start(); // uncomment and things work.
    Message.subscribe("thechannel", (message, globalId, messageId) => {
      lastMessageId = messageId;
      Message.unsubscribe("thechannel");
      resolve(message)
    }, lastMessageId);
  });

  callApiAsync(params); // server responds immediately but triggers a background job which will be handled by Sidekiq.

  return await asyncResponsePromise;
}

The problem I am having is that getResults() is called repeatedly (user scrolling down to get more results); the first time is fine and the results are returned as soon as the backend publishes the message. Subsequent calls though don't return as soon as the message is published but rather, after the next poll starts (roughly 25s).

I see that when you unsubscribe the current long poll is aborted if there is one (https://github.com/discourse/message_bus/blob/main/assets/message-bus.js#L561). Why is that?

And if I stop/start message bus just before subscribing, that seems to work around the problem. But I wanted to know if I'm misusing the MessageBus by repeatedly subscribing/unsubscribing like this?

Start with assets/message-bus.js around line 561 and trace how unsubscribe interacts with the active long poll. Reproduce repeated getResults() calls using the subscribe/unsubscribe pattern, then determine whether the behavior is expected and document why the next poll is delayed or what usage guidance is needed.