sceptre delete with ignore-dependencies fails

[zaro0508]

Execute sceptre delete with ignore-dependencies flag causes a "ValueError: max_workers must be greater than 0". The exact command works fine when the ignore-dependencies flag is not used.

Environment is Python 3.6.3 and Sceptre 2.3.0

working exeuction

➜  sceptre delete develop/sc-product-assoc-ec2
The following stacks, in the following order, will be deleted:
develop/sc-product-assoc-ec2-linux-windows-jumpcloud
develop/sc-product-assoc-ec2-linux-jumpcloud-notebook
develop/sc-product-assoc-ec2-linux-jumpcloud-workflows
develop/sc-product-assoc-ec2-linux-jumpcloud

Do you want to delete 'develop/sc-product-assoc-ec2' [y/N]: y
[2020-05-04 19:39:56] - develop/sc-product-assoc-ec2-linux-windows-jumpcloud - Deleting stack
[2020-05-04 19:39:56] - develop/sc-product-assoc-ec2-linux-jumpcloud-notebook - Deleting stack
[2020-05-04 19:39:56] - develop/sc-product-assoc-ec2-linux-jumpcloud-workflows - Deleting stack
..
..

Failing execution:

➜  sceptre --ignore-dependencies delete develop/sc-product-assoc-ec2
The following stacks, in the following order, will be deleted:

Do you want to delete 'develop/sc-product-assoc-ec2' [y/N]: y
Traceback (most recent call last):
  File "/Users/zaro0508/.virtualenvs/py36-default/bin/sceptre", line 8, in <module>
    sys.exit(cli())
  File "/Users/zaro0508/.virtualenvs/py36-default/lib/python3.6/site-packages/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/Users/zaro0508/.virtualenvs/py36-default/lib/python3.6/site-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/Users/zaro0508/.virtualenvs/py36-default/lib/python3.6/site-packages/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/Users/zaro0508/.virtualenvs/py36-default/lib/python3.6/site-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/Users/zaro0508/.virtualenvs/py36-default/lib/python3.6/site-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/Users/zaro0508/.virtualenvs/py36-default/lib/python3.6/site-packages/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/Users/zaro0508/.virtualenvs/py36-default/lib/python3.6/site-packages/sceptre/cli/helpers.py", line 36, in decorated
    return func(*args, **kwargs)
  File "/Users/zaro0508/.virtualenvs/py36-default/lib/python3.6/site-packages/sceptre/cli/delete.py", line 65, in delete_command
    responses = plan.delete()
  File "/Users/zaro0508/.virtualenvs/py36-default/lib/python3.6/site-packages/sceptre/plan/plan.py", line 140, in delete
    return self._execute(*args)
  File "/Users/zaro0508/.virtualenvs/py36-default/lib/python3.6/site-packages/sceptre/plan/plan.py", line 40, in _execute
    return executor.execute(*args)
  File "/Users/zaro0508/.virtualenvs/py36-default/lib/python3.6/site-packages/sceptre/plan/executor.py", line 49, in execute
    with ThreadPoolExecutor(max_workers=self.num_threads) as executor:
  File "/usr/local/var/pyenv/versions/3.6.3/lib/python3.6/concurrent/futures/thread.py", line 104, in __init__
    raise ValueError("max_workers must be greater than 0")
ValueError: max_workers must be greater than 0

[ngfgrant]

Obviously this a terrible error message. Happens when there are no stacks recognised to act on and our thread pool for executing is 0.

Would you be able to post a demo stack of this so we can try and trace why this wouldn't work for delete?

[zaro0508]

will do @ngfgrant

[zaro0508]

hmm, I can't seem to reproduce this issue with a simple sceptre project. My real project uses sceptre resolvers and hooks which might be causing the problem. Unfortunately that's not real easy for me to test.

[zaro0508]

The command that generated this error uses the greedy pattern matching feature that was in ver 2.3 but was removed (in PR #731) for ver 2.4. I suspect that this error is due to using greedy pattern match. However since it has been removed in ver 2.4 we probably won't see it anymore.