ResultSet returned by subscribe() in production mode is different from dev mode: return requestId in production mode

[Sephirus]

Hi guys,

For the last months I've been working on an analytics platform that's using Cube in the background. I've configured many dashboards, with the majority having real time indicators. I've built everything while working with dev mode = true but recently, due to the proximity to the client delivery I've started making tests with Cube configured in production mode. For that I've followed the steps you have in the documentation but one problem appeared.
I'm using the subscribe function to listen on changes related to the real time indicators and I've noticed that the resultSet that is returned have less fields in production mode.

Here you can see, the result set returned with dev mode = true

And here you can see the result set returned with dev mode = false

The problem is, I'm in need of the requestId of every single indicator, because it is the only way i know so later i can unsubscribe that request.

One real use case that I have is, I have one real time indicator with the time filter "today", and for this I subscribe it. If I change the time filter for yesterday, i will create a new subscription, because it's a new query, and for this I need to unsubscribe the previous one.

I'll leave a peace of my code and note that I use the requestId so I can store the messageId associated in the html so later I can use sendMessage to unsubscribe.

cubejsApiWebTransport.subscribe(request, {}, (error, resultSet) => {
  var requestId;
  
  if(resultSet != null && resultSet.loadResponses[0] != null){
	  requestId = resultSet.loadResponses[0].requestId;
	  
	  var messages = cubejsApiWebTransport.transport.messageIdToSubscription;
	  
	  Object.keys(messages).forEach(function(key,index) {
		  var newMessageId = key;
		  var newRequestId;
		  
		  if(messages[newMessageId] != null && messages[newMessageId].message != null){
			  newRequestId = messages[newMessageId].message.requestId;
			  
			  if(requestId != null && requestId.indexOf(newRequestId) >= 0){
				  indContainer.attr('data-messageId', newMessageId);
			  }
		  }
	  });
  }
...

As I said in the beginning, this is working fine with dev mode = true and I would like to understand if in production mode there is a way to force cube to send the requestId or to get it in other way.

Version:
0.33.38

Thanks in advance,
Filipe

[github-actions]

If you are interested in working on this issue, please leave a comment below and we will be happy to assign the issue to you.
If this is the first time you are contributing a Pull Request to Cube.js, please check our contribution guidelines.
You can also post any questions while contributing in the #contributors channel in the Cube.js Slack.

[paveltiunov]

@Sephirus It's intended behavior however I don't see any reason why can't we add requestId to all responses.

[Sephirus]

Hello @paveltiunov,

I just didn't understand why the intended behavior is different from dev and prod mode but let me try to explain my use case and maybe there's another way around for my problem.

I have multiple dashboards, each one of them with multiple charts. Some of these charts are real-time and some are not. For every chart we allow the user to update in real time two query parameters, the date range (today, yesterday, last 7 days, etc.) and the granularity (hour, day, week, etc.).

With all this in mind the problem that I have only happens with real time charts, because as I load a chart with a given query I will subscribe to it and receive updates. But if in the meantime the user updates the date range, a new subscription will me made, and now I have two subscriptions for the same chart and only one of them is accurate.

Up until now I was using the requestID so I could link a chart to a request and to a subscription. This way i would know if a given requestID already has a subscription, I need to first unsubscribe it. Like I said, with dev mode on everything works like a charm but in prd mode the requestID is not being returned so there's no way for me, so far as I know, to clean any other subscriptions of that chart alone.

If you have any other way to do this, I would love to hear from you.

Thanks

[Sephirus]

Hello again guys,

@paveltiunov any feedback on this matter?

Thanks