Functions in que are processed before functions in cmd

[bozghiyy]

Type of issue

unexpected behavior / questions

Description

The function queued using pbjs.que are processed before functions queued with pbjs.cmd before prebid library is loaded

Steps to reproduce

Queue any function (even a console log) with pbjs.que and pbjs.cmd and observe the execution order.

Test page

https://jsfiddle.net/bozghiyy/2ndgv504/

Expected results

The function to execute in the order that they are queued.

Actual results

Function queued with pbjs.que are processed first until prebid library is loaded and all the queues are processed. After that functions are processed in the order that are queued.

Platform details

All. Independent of platform.

Other information

Probably is due https://github.com/prebid/Prebid.js/blob/master/src/prebid.js#L981-L982, processing first que and then cmd.

It can cause issues when trying to run some prebid commands from a 3rd party script, the order or execution is unknown since is a race condition between prebid library and the 3rd party script. If you are aware how they work, it can be mitigated.

I do not know if I would consider this a bug and if anything needs to be "fixed", I wanted just to know an opinion if this is the intended way.
My questions would be:

• We will always have cross-compatibility for que and cmd? (maybe one should be removed in a major release)
• If there is a priority in execution process queue, shouldn't cmd be first? (alphabetically and is the preferred method)

[patmmccann]

As an aside, the chromium team is recommending async processing of these

#10062 (comment)

[dgirardi]

It can cause issues when trying to run some prebid commands from a 3rd party script, the order or execution is unknown since is a race condition between prebid library and the 3rd party script. If you are aware how they work, it can be mitigated.

What scenario do you have in mind? I can't think of any way to be sure of how your commands will line up if you're setting them up from a 3rd party script - even if you had just one queue.

We will always have cross-compatibility for que and cmd? (maybe one should be removed in a major release)

I agree they are redundant - but I am not sure about getting rid of one as it'd be asking users to potentially do a lot of work for very little gain.

If there is a priority in execution process queue, shouldn't cmd be first? (alphabetically and is the preferred method)

Reasonable, but again at this point it's more likely to create problems than to be an improvement.

[bozghiyy]

What scenario do you have in mind? I can't think of any way to be sure of how your commands will line up if you're setting them up from a 3rd party script - even if you had just one queue.

Is more about the un-reliability and lack of knowledge. If you understand how it works, there are ways around it.
For example:
If you have hard-coded on the page (with cmd):
pbjs.cmd.push(function() { pbjs.setConfig({ bidderTimeout: 2000 }); });
And you want to change that from a script.js file (with que):
pbjs.que.push(function() { pbjs.setConfig({ bidderTimeout: 3000 }); });
The value of bidderTimeout will depend when script.js will load against prebid.js

• if prebid.js loads first, it will execute the code on page first and when script.js loads it will execute the code, resulting the setting to be 3000
• if script.js loads first, it will queue in que and when prebid.js loads it will execute que first (setting it to 3000), then cmd setting it to 2000

So, will get two results, with same code, just depending when the files are loaded.
But that's an easy solve, just by using cmd in the script file. And will be always last to execute.

I do not think is really a bug, more the lack of knowledge on how this works. Probably this is encountered on complex implementations from companies with resources to troubleshoot it, so I do not think any change is needed but maybe is good just to have the issue here to be found, just in case.

I agree they are redundant - but I am not sure about getting rid of one as it'd be asking users to potentially do a lot of work for very little gain.

I agree is little to gain. This is the situation now and this is how it works. Changing it will probably introduce a lot of problems.
Just wanted an opinion if there are any plans to change it, so I know how to approach it.
No change sounds very reasonable. So I will close this, since I do not think there is anything else to do here.