Change:
t.Fatalf("unexpected faked discovery return value: %q", sv.GitCommit) } } <ins> func TestFakingServerVersionWithError(t *testing.T) { expectedError := errors.New("an error occurred") fakeClient := fakeclientset.NewSimpleClientset() fakeClient.Discovery().(*fakediscovery.FakeDiscovery).PrependReactor("*", "*", func(action kubetesting.Action) (handled bool, ret runtime.Object, err error) { return true, nil, expectedError }) _, err := fakeClient.Discovery().ServerVersion() if err == nil { t.Fatal("ServerVersion should return error, returned nil instead") } if err != expectedError { t.Fatal("ServerVersion should return expected error, returned different error instead") } } </ins>

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: I was trying to write a test in a service I'm working on to catch if an error returns from . When I overrode the result of the fake client with a reactor to return an error I did not get the error back. What you expected to happen: If the reactor is set to return an error, it should come back. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: This only happens with the fake. Environment: Kubernetes version (use ): 1.14 Cloud provider or hardware configuration: any OS (e.g: ): any Kernel (e.g. ): any Install tools: any Network plugin and version (if this is a network-related bug): n/a Others:
/sig testing
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Let's take a look at this /priority important-longterm /sig api-machinery /remove-sig testing /remove-lifecycle rotten
Is there any progress?
I submited a PR to fix this issue. PTAL .
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with .

Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
^^^ would it be possible to reconsider this PR? I ran into the same issue today.
this hasn't been fixed and we recently ran into this issue. Can we /reopen? Happy to bring up to date.
/reopen still relevant as above
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/remove-lifecycle rotten /triage accepted
/assign