8000 Ensure -PipelineVariable is set for all output from script cmdlets by vexx32 · Pull Request #12766 · PowerShell/PowerShell · GitHub
[go: up one dir, main page]

Skip to content

Conversation

@vexx32
Copy link
Collaborator
@vexx32 vexx32 commented May 23, 2020

PR Summary

Previously, -PipelineVariable was only set for the first occurence of output from a script cmdlet. This change borrows some code from the handling for compiled commands to ensure -PipelineVariable is always set correctly and should behave as expected even for script cmdlets.

PR Context

This PR resolves #10932, see this issue for further discussion.

We will need to document the bugged behaviour for downlevel versions of PowerShell in docs so that users are aware. Most folks probably won't have noticed it, but people may still run into it from time to time on downlevel versions.

@SteveL-MSFT I'm not 100% sure, but this feels like the kind of fix y'all might want in a servicing release for 7.0. 🙂

PR Checklist

@ghost ghost assigned TravisEz13 May 23, 2020
@vexx32 vexx32 requested review from daxian-dbw and rjmholt May 23, 2020 06:25
@vexx32
Copy link
Collaborator Author
vexx32 commented May 23, 2020

Codefactor and Codacy issues are with untouched code areas / not applicable. 🙂

@vexx32 vexx32 force-pushed the Functions/PipelineVariableFix branch 2 times, most recently from 1ef6559 to 3a12833 Compare May 23, 2020 06:30
@TravisEz13
Copy link
Member

I think this falls into a bucket 3 breaking change and I think we should take the change.
@PowerShell/powershell-committee Please review

@TravisEz13 TravisEz13 added CL-BreakingChange Indicates that a PR should be marked as a breaking change in the Change Log Review - Committee The PR/Issue needs a review from the PowerShell Committee labels May 27, 2020
Copy link
Collaborator
@rjmholt rjmholt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me

@SteveL-MSFT
Copy link
Member

@PowerShell/powershell-committee reviewed this, we agree that the previous behavior was broken and falls under bucket 3 as a breaking change, so approve the intended new behavior

@SteveL-MSFT SteveL-MSFT added Committee-Reviewed PS-Committee has reviewed this and made a decision and removed Review - Committee The PR/Issue needs a review from the PowerShell Committee labels Jun 3, 2020
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm a little concerned that there isn't enough validation. Can you think of additional edges here that we should be poking?

Copy link
Collaborator Author
@vexx32 vexx32 Jun 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are probably numerous odd cases where this might crop up, but I can't think of any that are really different from the test case here. At the very least, this does cover the test case that we know is currently broken.

I've not seen any other cases crop up myself, nor had someone drop in the community channels with an issue that came down to this. I suspect that that's more due to -PipelineVariable being a bit more of a niche concept from the start, though.

Without knowing for sure about other broken cases, the best I can do is test a few other cases with multiple script cmdlets and various mixes of script / compiled cmdlets to see if the logic breaks down anywhere.

The only real unknown where I don't know what to actually expect is what is meant to happen if multiple cmdlets in the same pipeline declare the same pipeline variable. I'm not sure the expected behaviour there is even recorded anywhere. Best guess - the nearest command to the variable's usage will have its output in there at any given point...

If anyone else has cases they know to be broken / likely to break, I'd appreciate having those as well.

@ghost ghost added Waiting on Author The PR was reviewed and requires changes or comments from the author before being accept and removed Waiting on Author The PR was reviewed and requires changes or comments from the author before being accept labels Jun 3, 2020
@ghost ghost added the Review - Needed The PR is being reviewed label Jun 11, 2020
@ghost
Copy link
ghost commented Jun 11, 2020

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Mainainer, Please provide feedback and/or mark it as Waiting on Author

@TravisEz13 TravisEz13 closed this Jun 14, 2020
@ghost ghost removed the Review - Needed The PR is being reviewed label Jun 14, 2020
@TravisEz13 TravisEz13 reopened this Jun 14, 2020
@TravisEz13
Copy link
Member

@JamesWTruher can you respond to @vexx32

@ghost ghost added the Review - Needed The PR is being reviewed label Jun 22, 2020
@ghost
Copy link
ghost commented Jun 22, 2020

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Mainainer, Please provide feedback and/or mark it as Waiting on Author

@vexx32
Copy link
Collaborator Author
vexx32 commented Jun 24, 2020

@JamesWTruher please update your review / let me know if you have additional cases to cover with tests. Thanks! 💖

@vexx32 vexx32 requested a review from JamesWTruher July 17, 2020 22:21
Copy link
Collaborator
@JamesWTruher JamesWTruher left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can always add more validation if we find additional cases.

Previously, for script functions -PipelineVariable would only take
effect for the duration of the first output, and then stopped working.

Borrowed some code from the compiled cmdlets' implementation
which has always worked just fine. This appears to resolve the issue.

:bug: Fix NRE with dynamicparam

Dynamicparam blocks also do enter/exit scope, but seem to lack a state.
Workaround is to check for null state and fallback to previous
behaviour for dynamicparam blocks.

This should not cause any issues since output can't be passed from
dynamicparam, so -PipelineVariable can't be set from this block.
@vexx32 vexx32 force-pushed the Functions/PipelineVariableFix branch from 581f2c5 to 7b0a58b Compare October 15, 2020 01:22
@vexx32
Copy link
Collaborator Author
vexx32 commented Nov 11, 2020

@TravisEz13 is there anything left pending here? 🙂

@SteveL-MSFT SteveL-MSFT added this to the 7.2-Consider milestone Dec 9, 2020
@ghost ghost removed this from the 7.2-Consider milestone Dec 9, 2020
@ghost
Copy link
ghost commented Dec 9, 2020

Open PRs should not be assigned to milestone, so they are not assigned to the wrong milestone after they are merged. For backport consideration, use a backport label.

@rjmholt rjmholt merged commit 16e2b62 into PowerShell:master Dec 10, 2020
@ghost ghost removed the Review - Needed The PR is being reviewed label Dec 10, 2020
@rjmholt
Copy link
Collaborator
rjmholt commented Dec 10, 2020

Merged this so we can include it in the next preview in order to validate it better

@vexx32 vexx32 deleted the Functions/PipelineVariableFix branch December 10, 2020 21:47
@iSazonov iSazonov added the CL-General Indicates that a PR should be marked as a general cmdlet change in the Change Log label Dec 11, 2020
@iSazonov iSazonov added this to the 7.2.0-preview.2 milestone Dec 11, 2020
@ghost
Copy link
ghost commented Dec 15, 2020

🎉v7.2.0-preview.2 has been released which incorporates this pull request.:tada:

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CL-BreakingChange Indicates that a PR should be marked as a breaking change in the Change Log CL-General Indicates that a PR should be marked as a general cmdlet change in the Change Log Committee-Reviewed PS-Committee has reviewed this and made a decision

Projects

None yet

Development

Successfully merging this pull request may close these issues.

-PipelineVariable is only assigned output from the first execution of the first function block

8 participants

0