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

Add testing functionality for WaitExecution #393

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

bergsieker
Copy link
Collaborator

The existing ExecuteAndWait function will rarely actually call
WaitExecution when used against a live server. This change adds the
ability to terminate the Execute call early and switch to WaitExecution
immediately so that it's possible for service implementors to test
WaitExecution.

Retrying based on an operation error is always incorrect, although
mostly harmless. Once an operation has an error, it is marked as Done
and should never be unmarked, so retries will simply fetch the same
operation (with the same error) again.
The existing ExecuteAndWait function will rarely actually call
WaitExecution when used against a live server. This change adds the
ability to terminate the Execute call early and switch to WaitExecution
immediately so that it's possible for service implementors to test
WaitExecution.
@@ -255,6 +256,9 @@ func (c *Client) ExecuteAndWaitProgress(ctx context.Context, req *repb.ExecuteRe
progress(metadata)
}
}
if returnEarly {
return status.Error(codes.Internal, "fake error to for wait call")
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: "(...) error to for wait (...)", shouldn't it be, "(...) error to trigger the wait (...)"

// ForceEarlyWaitCalls specifies whether ExecuteAndWait should call WaitExecution immedately
// after receiving an Operation from Execute. It is primarily useful for testing
// WaitExecution.
ForceEarlyWaitCalls bool
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not inheretly opposed to this... But I think the most appropriate place for this behavior would be on the fake server: https://github.com/bazelbuild/remote-apis-sdks/blob/af1232ee0d79920ab8390fb855f95dca18a69cf0/go/pkg/fakes/exec.go. Wdyt?

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.

None yet

3 participants