Refactor: update dry run options and cleanup validator

[rvermootenct]

---

name: Pull Request about: Create a pull request to make a contribution labels:

---

IMPORTANT NOTICE: I read and understood the guidelines for contributions to the TRD. The contribution may qualify for being compensated by the TRD grant if approved by the maintainers.

This PR resolves the issue . The following steps were performed:

• Analysis: A user girl has many separate options for dry run. She is currently also forced into not using a signer.

• Solution: A user girl should have a a single dry run flag and not be forced into not using the signer.

• Implementation: I moved all of the dry run args into a singe dry run arg that has multiple choices, namely:

• signer (default)

• no_signer

• no_consumer

• no_signer_no_consumer

Allowing the user girl more granular control of how she would like to use the software.

I also spent some time continuing to clean up launch common by moving all the validation stuff into it's own file, creating new functions for each validation step and tested them individually. Before this was a bit of a black box and the nesting was getting very confusing. Tried to clean that up.

• Performed tests: Wrote 14 new tests, ran through all dry mode options. I do not have the ability to run through a non-dry run mode at this time and would request that one is done before merge as it touches so much.

• Documentation: I removed dry run no consumer from documentation. And added documentation for how dry run woks.

• Check list:

• [ ] I extended the Github Actions CI test units with the corresponding tests for this new feature (if needed).

• [ ] I extended the Sphinx documentation (if needed).

• [ x ] I extended the help section (if needed).

• [ ] I changed the README file (if needed).

• [ ] I created a new issue if there is further work left to be done (if needed).

Work effort: 8

[jdsika]

Let's aim for a merge today

[jdsika]

DID YOU TEST WITH A GHOSTNET BAKER?

[jdsika]

No ENUM use?

[nicolasochem]

Thanks. What's a "Consumer"?

Maybe find a better description for this mode of dry-run. What does it not do?

As far as I understand, the "consumer" takes the theoretical payouts and puts them into discrete operations and batches.

What's the use case for running "dry-run no consumer"?

In my opinion, it would be much better to remove the concept of "producer" and "consumer" altogether, see this discussion.

So at least let's not make it worse by surfacing this terminology to the user.

[jdsika]

hm, you may be right. I mean we currently do expose this to the user. It would have been a refactor which explains the differerent exisitng types of dry-runs better. It was confusing to me at least. But we can just deprecate the "no_consumer" option and clean it up internally later?