Scheduling a single element from a multiselect-list parameter behaves different scheduled than when run live

[mdmat]

In my production environment, when scheduling a script to be ran at a later time, selecting a single option from a multiselect-list parameter will transform arguments.

For example, if one of the allowed values was "peanut butter jelly" and another one was "spaghetti and meatballs", selecting only a single value will transform the argument into this: "p,e,a,n,u,t, ,b,u,t,t,e,r, ,j,e,l,l,y" or "s,p,a,g,h,e,t,t,i, ,a,n,d, ,m,e,a,t,b,a,l,l,s", which I imagine is unintended behavior. However, when selecting both options, the argument looks like this "peanut butter jelly,spaghetti and meatballs" which matches what I expect is intended behavior.

[bugy]

Hi @mdmat thanks for reporting!

[mdmat]

Hello @bugy glad to help. Some more information that may aid in bugfixing. When I view the .json file associated with the incorrectly-ran scheduled script, the value stored is correct, it is not until the server attempts to execute the script that it transforms it into its incorrect form.

Also, I spent some time digging through the code to find the service that executes these scheduled jobs, since that is where it seems to be tripping up. Is this here? I printed the parameter_values variable and it almost matched the values in the schedules .json file, the only difference being single vs double-quotes. I will keep digging for a little while longer.

[mdmat]

And here is some more info This appears to be how this is executed from the web interface while This appears to be how is it executed from the scheduler service.

I printed out the normalized values being passed into the executor by the web server versus the non-normalized values being passed into the executor with the scheduler service, and the major difference I spotted there is when there is a single value in the multiselect-list being scheduled, it is not being defined as a list, whereas when normalized, it is defined as a list.

[mdmat]

@bugy I believe I have the solution.

Starting right here

(add) normalized_values = dict(config.parameter_values) (add) execution_id = self._execution_service.start_script(config, normalized_values, user) (remove) execution_id = self._execution_service.start_script(config, parameter_values, user)

This now passes in the same normalized dictionary to the executor as the web interface does. I tested it in my production environment and it does function well for me, with the albeit very limited testing I have performed.

[bugy]

Hi @mdmat thanks for investigation. I fixed it in a similar way, but in different parts of code Could you check the changes (on dev version) once the build is ready?

[mdmat]

@bugy Sure thing, I'll keep an eye out for that build.

[bugy]

Hi @mdmat it took me some time, but finally I fixed the build and it should be available :)