Attempt to queue an RPCRequest to the server with client-only requests in the queue

[matus_b]

Hello Isomorphic.

We have a small problem after upgrade to SmartGWT 5.0.
In our code we have a form containing couple of Select items, which are bound to fields pointing at optional DataSources. Both this datasources have cacheAllData="true" and cacheMaxAge="3600".
After we upgraded the library to version 5.0 (build of 21 January 2016), opening this form results in warning shown:

Attempt to queue an RPCRequest to the server (URL: %server%) with client-only requests in the queue - the client-only requests will be sent immediately, clearing the transaction, and making the queue available for this (and subsequent) server-bound requests.

When taking a look at requests, we can see that fetch requests for those optional DataSources are made in a queue, which was not the case before the upgrade.

So, is there any way to handle this warning or to send fetch requests without queue?

[Isomorphic]

By "optional DataSources" do you mean optionDataSource, as in selectItem.optionDataSource?

It's not clear what problem you are trying to solve..

If you don't want queuing (it's unclear why this would be), you could use the optionFilterContext to specify rpcRequest.sendNoQueue for each SelectItem. We wouldn't recommend this, since queuing is generally a performance and scalability improvement.

If something aside from queueing is going wrong with some of these requests, please specify what's going wrong.

[matus_b]

Yes, optionDataSource.
The problem we have is that we see this warning in dev console:

Attempt to queue an RPCRequest to the server (URL: %server%) with client-only requests in the queue - the client-only requests will be sent immediately, clearing the transaction, and making the queue available for this (and subsequent) server-bound requests.

Is that intended?
Actual functionality is ok, nothing is broken, it's just the warning what disturbs us.

[Isomorphic]

OK, please clarify next time that the warning is the only problem.

This warning should be harmless. We don't have a complete enough picture of your usage here to be sure, but it seems like this warning is likely to disappear when you upgrade to 5.1 as well.