Fix action executor to prevent blocking Taskomatic for actions that are already finished

[wweellddeerr]

What does this PR change?

The server actions can be manually cancelled via Web UI, so this PR changes the code to check if all server actions have already finished before putting the Taskomatic thread to sleep. It should prevent blocking the Taskomatic for actions that will never appear in the database.

GUI diff

No difference.

• DONE

Documentation

• No documentation needed: only internal and user invisible changes

• DONE

Test coverage

• No tests: already covered

• DONE

Links

Port of https://github.com/SUSE/spacewalk/pull/22295

• DONE

Changelogs

Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository

If you don't need a changelog check, please mark this checkbox:

• No changelog needed

If you uncheck the checkbox after the PR is created, you will need to re-run changelog_test (see below)

Re-run a test

If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run:

• Re-run test "changelog_test"
• Re-run test "backend_unittests_pgsql"
• Re-run test "java_pgsql_tests"
• Re-run test "schema_migration_test_pgsql"
• Re-run test "susemanager_unittests"
• Re-run test "javascript_lint"
• Re-run test "spacecmd_unittests"

[github-actions]

Suggested tests to cover this Pull Request

[lucidd]

does this mean an action with no server actions does never count as having all server actions finished?

[lucidd]

i guess it makes sense given the countQueuedServerActions(action) == 0 check already. I'm not exactly sure in what scenario an action would be saved and scheduled without server actions and then in a separate transaction server actions get added. It sounds like all kinds of problematic.

[wweellddeerr]

I don't really know if it is possible to have an action here that has no server actions reaching this point of the code. I agree that it would be very problematic.

I just know that it is not what I'm searching for, maybe it just never happens. My point is that if the action has server actions and they are all finished I should not block the Taskomatic thread waiting for actions to appear as QUEUED in the database.

If this hypothetical case (having action without server actions) eventually happens I just want to keep the behavior exactly like it is today, and that is the reason to check if the list is not empty.

[wweellddeerr]

Are you OK with that? I can remove this check or even rename the method if you think it is necessary.

[lucidd]

i think its fine for now. The code suggests that there are cases where the action has no server actions initially. The whole action hand off between tomcat and taskomatic seems just very fragile so i think this needs some proper way in the future.