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

Proto changes for showing ExecuteResponse in the UI #5502

Merged
merged 1 commit into from
Dec 13, 2023

Conversation

bduffany
Copy link
Member

@bduffany bduffany commented Dec 11, 2023

This PR adds the proto changes needed to show ExecuteResponse in the action page instead of ActionResult. Showing ExecuteResponse has two advantages:

  • It means we'll show the actual ExecuteResponse for the execution ID, rather than the latest ActionResult associated with the action digest. The latter is inaccurate/incorrect and often confusing.
  • The ExecuteResponse contains a superset of info, such as:
    • The status field (execution error details when the task either fails to start, or terminates abnormally), which is not representable by an ActionResult.
    • An optional server_logs field which allows attaching arbitrary logs. We can use this for attaching firecracker VM logs.

Note, this does NOT take any steps towards addressing https://github.com/buildbuddy-io/buildbuddy-internal/issues/2918 which is a bit more involved as it will likely involve DB schema changes.

Related issues:

// [build.bazel.remote.execution.v2.ExecuteResponse] produced by the executor
// for the latest attempt of this execution.
//
// This digest can be used to fetch a specially formatted ActionResult from
Copy link
Member

Choose a reason for hiding this comment

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

Kind of ambivalent here, but did you consider putting this in the CAS instead as the hashed(executeResponse) minus this field?

Copy link
Member Author

@bduffany bduffany Dec 11, 2023

Choose a reason for hiding this comment

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

Yeah, I figured the downside of that approach is that we have to store the digest somewhere, whereas this approach would just hash the execution_id that we already store - similar to how we add the invocation ID to the Action digest today for failed actions. I am hesitant to add more columns to the Executions table but if you don't think it's a big deal, we can do that instead.

@bduffany bduffany merged commit f0d9260 into master Dec 13, 2023
1 check failed
@bduffany bduffany deleted the execute-response branch December 13, 2023 21:35
@sluongng sluongng mentioned this pull request Dec 15, 2023
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.

3 participants