I used to add too many assertions, but do so much less these days - so I feel like I added this for a good reason.

I think a better fix would be to not pass the ast for the minishell code path because the parameter values no longer match up with the ast properly anyway.

@lzybkr: I'm sure there was a reason but, at the end of the day, test runs consistently fail against debug builds due to this assert and consistently pass in release builds. In short, this assert isn't providing any value since debug builds are only run privately.

if you do have a good reason for leaving it in, let me know. In lieu of one, I'm reluctant to make a functional change to address this.

The assertion caught a contract violation - the ast does not match the argument. Contract violations should not be "fixed" by ignoring the assertion.

If everything works today, code added in the future might not realize the contract is violated and do strange things.

You can make a change in this area with some confidence because it is well tested in our tests, there is plenty of time before the next release, and I will review the fix.

Then perhaps it shouldn't be an assert. The contract is being violated multiple times a test run right now.

It's an internal api for code that changes infrequently - an assert is reasonable.

@lzybkr: I have to say that I would be open to your argument if we had a process for running tests against debug builds but we don't and, in fact, this assert always failed in test runs.

That said, I'll update the PR with a proposed runtime fix.

@lzybkr: Do you have any additional feedback?