I was able to reproduce this. Many thanks for the pipeline example.
The problem seems to be that `filterable` is `Boolean` and shows up as `null` so it doesn't get passed down. Is it possible to set it to `false` explicitly?

        [$class: 'CascadeChoiceParameter',
            name: 'LEASE_TIME',
            choiceType: 'PT_SINGLE_SELECT',
            referencedParameters: 'MACHINE_TYPE',
            filterable: false,
            script:
                [$class: 'GroovyScript',
                    fallbackScript: [classpath: [], sandbox: false, script: ''],
                    script: [classpath: [], sandbox: false, script: get_choices()]
                ]
        ],

In my case yes, and it looks like it really resolves the problem.
However there's got to be another solution for when the script cannot be updated, or people just don't know what to update.

Maybe you also know who's responsible for changing how the first dropdown looks in 2.401.3? I'm not a fan, and they have introduced a bug anyway.

For the original problem reported:

kinow I don't have any error in the console log, however the execution order is wrong and because of this when the wrongly behaving choice element gets updated the input parameter is not yet set by the "previous" active choice element, hence the wrong output.

My pipeline config is also missing the explicit `filterable: false` declaration, and I see now that when pressing Save from the UI Configuration, it inserts this, then after the first build it is updated from the pipeline source again and takes it away.  I think the previous run where I only saw randomName entities updated was from a third run.  So probably adding filterable: false will be a workaround, but it would be nice if that parameter defaulted to false properly like in earlier versions, as it clutters the pipeline to have to explicitly set every option.

yes, please if the parameter could be set to false by default as it would require a lot of changes in numerous pipelines to put in an extra attribute.

Thanks

Some plugins contribute steps to the pipeline explicitly. In those cases, we can consider the custom step a public API.

This plugin does not do that, and many pipelines rely on doing this.
$class: 'CascadeChoiceParameter'
 

It feels a bit like relying on a private API.

kinow: Do you think the plugin should handle just that edge case? 

kinow : I've got a PR here - https://github.com/jenkinsci/active-choices-plugin/pull/85

I'll leave it to you to decide whether this is the behavior you want.

Fixed in jenkinsci/active-choices-plugin#85. Released in 2.7.2.

Unfortunately , my initially reported problem is still not solved in 2.7.2, (because the results are returned in wrong order, not all the active choices elements gets updated  with the correct values).

I had to revert to 2.6.5

szjozsef I am closing this ticket. Please file a separate ticket for any additional issues with steps to reproduce from scratch on a clean Jenkins installation.