Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Recursively search all AggregateException InnerExceptions for predicate matches when using HandleInner() #822

Closed
wants to merge 2 commits into from
Closed

Recursively search all AggregateException InnerExceptions for predicate matches when using HandleInner() #822

wants to merge 2 commits into from

Conversation

sideproject
Copy link
Contributor

Recursively search all AggregateException InnerExceptions for predicate matches when using HandleInner()

Related Issue: #818

(Apologies for the second PR, I had some trouble with the first one so I started over)

@sideproject sideproject mentioned this pull request Jan 23, 2021
Closed
martincostello
martincostello approved these changes Jan 24, 2021
View reviewed changes
Copy link
Member

@martincostello martincostello left a comment

Choose a reason for hiding this comment

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

Looks good to me. I wonder if it's worth also adding a further test case for where an AggregateException contains an AggregateException which then contains the exception being searched for?

@martincostello martincostello added this to the v7.2.2 milestone Jan 24, 2021
@sideproject
Copy link
Contributor Author

Good idea. I've added two more tests to verify that nested AggregateExceptions are also searched.

@martincostello
Copy link
Member

I'm not sure why the CI keeps failing, but it's missing some different changes I made to fix the CI in the v722-or-v730 branch this weekend. Could you rebase your branch with the latest changes to rule that out please?

Otherwise, this looks good to merge.

@sideproject
Copy link
Contributor Author

I just rebased from upstream and pushed - did it help?

@martincostello
Copy link
Member

Apparently not 😕

My only other guess is that the CI auto-versioning stuff doesn't like the name of your branch being the same name as the target branch as a PR I opened yesterday branched from the same point is fine: #823.

@sideproject
Copy link
Contributor Author

Would you like me to submit a new PR with a different branch name?

@martincostello
Copy link
Member

We could try to rule it out. If it does fix it then it'll be something to do with an old issue logged against the CI being flakey. If it doesn't then I'm a bit stumped.

Leave this one open for now and try opening another for a different branch name - if it works, then we can swap over to that PR, otherwise you can close it and we'll stick with this one.

@sideproject sideproject mentioned this pull request Jan 25, 2021
Merged
@martincostello
Copy link
Member

Yep, looks like the branch name was what is breaking it for some reason.

Will close this PR in favour of #824.

@martincostello martincostello removed this from the v7.2.2 milestone Jan 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@martincostello martincostello martincostello approved these changes

Assignees
No one assigned
Labels
bug fix
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@sideproject @martincostello