-
Notifications
You must be signed in to change notification settings - Fork 305
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
Groundwork for Streaming Progress Updates from View Service #3559
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just two comments from my end
message BuildProgress { | ||
// An approximate progress of the build, from 0 to 1. | ||
float progress = 1; | ||
} | ||
// Signals that the transaction is complete. | ||
message Complete { | ||
// The finished transaction. | ||
penumbra.core.transaction.v1alpha1.Transaction transaction = 1; | ||
} | ||
oneof status { | ||
BuildProgress build_progress = 1; | ||
Complete complete = 2; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like these can be unnested so it can be shared with WitnessAndBuildResponse too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, feel free to pick it up, we'll also have to propagate these changes through the rest of the source code.
// Signals that building is in progress. | ||
message BuildProgress { | ||
// An approximate progress of the build, from 0 to 1. | ||
float progress = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this correlate to the % of actions that have been built thus far?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's up to the implementation, I guess, in principle an implementation that had insight into how much proving was done as it was happening could give better updates. I believe there's a way to get Rayon to do this on the Rust side. I think at the proto level we should be as agnostic as possible, and initially, we should just try to expose info we have rather than adding progress plumbing into the proving internals.
There's something off with the CI, this PR is green but it should definitely be red, it's half-finished and only changes protos, doesn't recompile them or propagate changes through the rest of the codebase. @conorsch any ideas? |
Good catch, I think I broke this back in #3297, which altered the behavior so that the buf checks were run only when the PR is first opened, but not every time it's changed. Updated the logic in #3575, once that's in let's rebase this one and confirm we see the buf checks again! |
974b665
to
8210c17
Compare
Blocked on #3621 |
WIP Compiles BroadcastTransactionResponse Get code and tests compiling lint BroadcastTransaction comment next steps Rebuild proto Remove unused imports N.B. this commit was squashed by @conorsch
a33eb4f
to
6a2413b
Compare
6a2413b
to
f73d92c
Compare
CI is now passing on this PR, module the protobuf lint failure, which is to be expected, because the proto changes here are Breaking Changes™. Will continue investigation of sweep test in #3621. Proceeding with merge here to unblock web impl consuming this new interface. |
Sketch of one possibility for #3549 for discussion. (No code changes as yet, only proto changes).