--start-at-task only respected for first batch of serial

[chamini2]

Summary

When I set serial, it correctly starts at the task passed in the flag, but for the second batch it ignores it and starts from the beggining of the playbook.

Issue Type

Bug Report

Component Name

playbook

Ansible Version

❯ ansible --version
ansible [core 2.15.4]
  config file = /Users/matteo/Projects/fal-ai/fal_terraform/modules/distributed_workers/ansible.cfg
  configured module search path = ['/Users/matteo/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /opt/homebrew/Cellar/ansible/8.4.0/libexec/lib/python3.11/site-packages/ansible
  ansible collection location = /Users/matteo/.ansible/collections:/usr/share/ansible/collections
  executable location = /opt/homebrew/bin/ansible
  python version = 3.11.5 (main, Aug 24 2023, 15:09:45) [Clang 14.0.3 (clang-1403.0.22.14.1)] (/opt/homebrew/Cellar/ansible/8.4.0/libexec/bin/python)
  jinja version = 3.1.2
  libyaml = True

Configuration

CONFIG_FILE() = /Users/matteo/Projects/fal-ai/fal_terraform/modules/distributed_workers/ansible.cfg
DEFAULT_FORKS(/Users/matteo/Projects/fal-ai/fal_terraform/modules/distributed_workers/ansible.cfg) = 20

OS / Environment

macbook M2 13.2.1 (22D68)

❯ uname -a
Darwin ... 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 30 20:38:43 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T8112 arm64

Steps to Reproduce

1. playbook

   - name: Start at error
     hosts: all
     serial: "10%"
     tasks:
       - name: first
         debug:
           msg: "first"
   
       - name: second
         debug:
           msg: "second"

2. ❯ ansible-playbook -i inventory.yaml --start-at-task second

Expected Results

PLAY [Start at error] ****************************************************************************************************************************************

TASK [Gathering Facts] ***************************************************************************************************************************************
ok: [...]
ok: [...]
ok: [...]
ok: [...]
ok: [...]

TASK [second] ************************************************************************************************************************************************
ok: [...] => {
    "msg": "second"
}
ok: [...] => {
    "msg": "second"
}
ok: [...] => {
    "msg": "second"
}
ok: [...] => {
    "msg": "second"
}
ok: [...] => {
    "msg": "second"
}

PLAY [Start at error] ****************************************************************************************************************************************

TASK [Gathering Facts] ***************************************************************************************************************************************
ok: [...]
ok: [...]
ok: [...]
ok: [...]
ok: [...]

TASK [second] ************************************************************************************************************************************************
ok: [...] => {
    "msg": "second"
}
ok: [...] => {
    "msg": "second"
}
ok: [...] => {
    "msg": "second"
}
ok: [...] => {
    "msg": "second"
}
ok: [...] => {
    "msg": "second"
}

Actual Results

PLAY [Start at error] ****************************************************************************************************************************************

TASK [Gathering Facts] ***************************************************************************************************************************************
ok: [...]
ok: [...]
ok: [...]
ok: [...]
ok: [...]

TASK [second] ************************************************************************************************************************************************
ok: [...] => {
    "msg": "second"
}
ok: [...] => {
    "msg": "second"
}
ok: [...] => {
    "msg": "second"
}
ok: [...] => {
    "msg": "second"
}
ok: [...] => {
    "msg": "second"
}

PLAY [Start at error] ****************************************************************************************************************************************

TASK [Gathering Facts] ***************************************************************************************************************************************
ok: [...]
ok: [...]
ok: [...]
ok: [...]
ok: [...]

TASK [first] *************************************************************************************************************************************************
ok: [...] => {
    "msg": "first"
}
ok: [...] => {
    "msg": "first"
}
ok: [...] => {
    "msg": "first"
}
ok: [...] => {
    "msg": "first"
}
ok: [...] => {
    "msg": "first"
}

TASK [second] ************************************************************************************************************************************************
ok: [...] => {
    "msg": "second"
}
ok: [...] => {
    "msg": "second"
}
ok: [...] => {
    "msg": "second"
}
ok: [...] => {
    "msg": "second"
}
ok: [...] => {
    "msg": "second"
}

Code of Conduct

• I agree to follow the Ansible Code of Conduct

[ansibot]

Files identified in the description:

None

If these files are incorrect, please update the component name section of the description or use the component bot command.

[chamini2]

@sivel , any pointers to how I might help fix this?

[bcoca]

At this point I would deprecate and remove the feature and implement actual breakpoints.

fixing it requires redesigning the feature to account for batching/serial as task names are not unique and the way it is cleared right now is required to actually be able to move on after the specified task.

[chamini2]

Is --start-at-task deprecated? What is the appropriate way to start at a task?

[bcoca]

It is not deprecated, I'm just saying that could be an option going forward, that user expectations have gone far from what it does and how it was designed and that we might require scraping the current feature in favor of something that is more robust, complete and can actually meet this type of usage

[chamini2]

But you suggested implementing breakpoints, which is not what I really wanted using this. I wanted the run to skip a few steps and start from a certain task. How would we achieve this with breakpoints?

[bcoca]

The breakpoints themselves would not do it, but make it possible to implement set a breakpoint, run play 'skipping up to X breakpoint' or 'run to X breakpoint and start -steps', etc , they would also not require 'clearing' as there would not be any possible duplication (like with task name), so they can apply per batch, which is your use case.

But the feature goes well beyond just this specific case, this was just the 'latest' in a series of requests that convinced me we do actually need this in the engine.

[chamini2]

Oh, OK OK. I think I understand now, thanks for clarifying.

Is there a proposal for breakpoints already that I can look at?

I would like to help with whatever is need to achieve a behavior like what you described.

[bcoca]

its coalescing in my head, I posted here to make sure i follow up, mostly creating the breakpoints themselves should be pretty simple, a hidden task attribute, declaring them for a run and handling them will require fixes to the base strategy class, play iterator and task execution ... that requires more thinking/time.

[Hapshanko]

But you suggested implementing breakpoints, which is not what I really wanted using this. I wanted the run to skip a few steps and start from a certain task. How would we achieve this with breakpoints?

Do tags not help you here? You can use skip tags or run tags to choose which parts to run.

[chamini2]

But you suggested implementing breakpoints, which is not what I really wanted using this. I wanted the run to skip a few steps and start from a certain task. How would we achieve this with breakpoints?

Do tags not help you here? You can use skip tags or run tags to choose which parts to run.

It could help! I will check it out. Still --start-at-task would seem to be behaving in an unexpected way imho