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.

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

core: add missing error type check to exec #8751

Merged

Conversation

BlaineEXE
Copy link
Member

In ExtractExitCode, there is one error type that can be valid as a
pointer or not-as-a-pointer. Add a case to the type check for the
non-pointer condition.

Resolves #8280

Signed-off-by: Blaine Gardner blaine.gardner@redhat.com

Description of your changes:

Which issue is resolved by this Pull Request:
Resolves #

Checklist:

  • Commit Message Formatting: Commit titles and messages follow guidelines in the developer guide.
  • Skip Tests for Docs: Add the flag for skipping the build if this is only a documentation change. See here for the flag.
  • Skip Unrelated Tests: Add a flag to run tests for a specific storage provider. See test options.
  • Reviewed the developer guide on Submitting a Pull Request
  • Documentation has been updated, if necessary.
  • Unit tests have been added, if necessary.
  • Integration tests have been added, if necessary.
  • Pending release notes updated with breaking and/or notable changes, if necessary.
  • Upgrade from previous release is tested and upgrade user guide is updated, if necessary.
  • Code generation (make codegen) has been run to update object specifications, if necessary.

@BlaineEXE
Copy link
Member Author

@leseb I'm not sure how you were testing this before, but I'm pretty sure this will fix the issue. I'm going to add unit tests to be more sure of it, but it would be good to be able to run the real life test manually to be sure.

@BlaineEXE BlaineEXE added the do-not-merge DO NOT MERGE :) label Sep 19, 2021
@BlaineEXE
Copy link
Member Author

BlaineEXE commented Sep 19, 2021

TODO:

  • create unit test for this

@leseb
Copy link
Member

leseb commented Sep 20, 2021

@leseb I'm not sure how you were testing this before, but I'm pretty sure this will fix the issue. I'm going to add unit tests to be more sure of it, but it would be good to be able to run the real life test manually to be sure.

I swear I had tested that too and each time I was not able to enter the right case and displaying the error type was not showing a pointer. Anyway, I think this does not hurt.

@BlaineEXE BlaineEXE force-pushed the add-error-type-assertion-to-exec-package branch 2 times, most recently from 0326aa1 to a08545d Compare September 20, 2021 17:38
Copy link
Member

@leseb leseb left a comment

Choose a reason for hiding this comment

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

I'm not sure if this will fix the issue but better coverage is nice. Thanks!

pkg/util/exec/exec_test.go Outdated Show resolved Hide resolved
@leseb
Copy link
Member

leseb commented Sep 22, 2021

@Mergifyio rebase

@mergify
Copy link

mergify bot commented Sep 22, 2021

Command rebase: success

Branch has been successfully rebased

@leseb leseb force-pushed the add-error-type-assertion-to-exec-package branch from a08545d to 4a0423d Compare September 22, 2021 07:57
Copy link
Member

@leseb leseb left a comment

Choose a reason for hiding this comment

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

nit and 1 question

pkg/util/exec/exec_test.go Outdated Show resolved Hide resolved
if strings.Contains(err.Error(), "command terminated with exit code") {
a := strings.SplitAfter(err.Error(), "command terminated with exit code")
return strconv.Atoi(strings.TrimSpace(a[1]))
}
return 0, errors.Errorf("error %#v is not an ExitError nor CodeExitError but is %v", err, reflect.TypeOf(err))
return 0, errors.Errorf("error %#v is an unknown error type: %v", err, reflect.TypeOf(err))
Copy link
Member

Choose a reason for hiding this comment

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

Afterthoughts, should we return something else than 0 if we return an unknown error?

Copy link
Member Author

Choose a reason for hiding this comment

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

I had a similar thought. Let me do that.

@BlaineEXE BlaineEXE force-pushed the add-error-type-assertion-to-exec-package branch 2 times, most recently from 9351bff to d449828 Compare September 22, 2021 18:36
In ExtractExitCode, there is one error type that can be valid as a
pointer or not-as-a-pointer. Add a case to the type check for the
non-pointer condition.

Resolves rook#8280

Signed-off-by: Blaine Gardner <blaine.gardner@redhat.com>
@BlaineEXE BlaineEXE force-pushed the add-error-type-assertion-to-exec-package branch from d449828 to bc494f5 Compare September 22, 2021 20:16
@leseb
Copy link
Member

leseb commented Sep 23, 2021

@BlaineEXE is the DNM label still relevant?

@BlaineEXE BlaineEXE removed the do-not-merge DO NOT MERGE :) label Sep 23, 2021
@BlaineEXE BlaineEXE merged commit 823d045 into rook:master Sep 23, 2021
@BlaineEXE BlaineEXE deleted the add-error-type-assertion-to-exec-package branch September 23, 2021 20:25
travisn added a commit that referenced this pull request Sep 24, 2021
core: add missing error type check to exec (backport #8751)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

do proper error type assertion in exec package
3 participants