-
Notifications
You must be signed in to change notification settings - Fork 801
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
[Merged by Bors] - Use only lighthouse types in the mock builder #4793
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.
Fantastic! Should hopefully make compilation a bit lighter with those deps removed
impl<E: EthSpec> BidStuff<E> for BuilderBid<E, BlindedPayload<E>> { | ||
fn set_fee_recipient(&mut self, fee_recipient: Address) { | ||
match self.header.to_mut() { | ||
BlindedPayloadRefMut::Merge(payload) => { |
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.
Wanted to rewrite this with a mapping macro but realised it isn't possible. Opened an issue on superstruct: sigp/superstruct#31
bors r+ |
## Proposed Changes - only use LH types to avoid build issues - use warp instead of axum for the server to avoid importing the dep ## Additional Info - wondering if we can move the `execution_layer/test_utils` to its own crate and import it as a dev dependency - this would be made easier by separating out our engine API types into their own crate so we can use them in the test crate - or maybe we can look into using reth types for the engine api if they are in their own crate Co-authored-by: realbigsean <[email protected]>
This PR was included in a batch that was canceled, it will be automatically retried |
bors r- |
Canceled. |
bors r+ |
bors r- |
Canceled. |
bors r+ |
## Proposed Changes - only use LH types to avoid build issues - use warp instead of axum for the server to avoid importing the dep ## Additional Info - wondering if we can move the `execution_layer/test_utils` to its own crate and import it as a dev dependency - this would be made easier by separating out our engine API types into their own crate so we can use them in the test crate - or maybe we can look into using reth types for the engine api if they are in their own crate Co-authored-by: realbigsean <[email protected]>
Build failed (retrying...): |
## Proposed Changes - only use LH types to avoid build issues - use warp instead of axum for the server to avoid importing the dep ## Additional Info - wondering if we can move the `execution_layer/test_utils` to its own crate and import it as a dev dependency - this would be made easier by separating out our engine API types into their own crate so we can use them in the test crate - or maybe we can look into using reth types for the engine api if they are in their own crate Co-authored-by: realbigsean <[email protected]>
Build failed (retrying...): |
## Proposed Changes - only use LH types to avoid build issues - use warp instead of axum for the server to avoid importing the dep ## Additional Info - wondering if we can move the `execution_layer/test_utils` to its own crate and import it as a dev dependency - this would be made easier by separating out our engine API types into their own crate so we can use them in the test crate - or maybe we can look into using reth types for the engine api if they are in their own crate Co-authored-by: realbigsean <[email protected]>
Build failed: |
bors r+ |
## Proposed Changes - only use LH types to avoid build issues - use warp instead of axum for the server to avoid importing the dep ## Additional Info - wondering if we can move the `execution_layer/test_utils` to its own crate and import it as a dev dependency - this would be made easier by separating out our engine API types into their own crate so we can use them in the test crate - or maybe we can look into using reth types for the engine api if they are in their own crate Co-authored-by: realbigsean <[email protected]>
Build failed: |
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.
Thanks Sean!
pub fn set_mock_builder( | ||
&mut self, | ||
beacon_url: SensitiveUrl, | ||
) -> impl std::future::Future<Output = ()> { |
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.
nit:
pub fn set_mock_builder( | |
&mut self, | |
beacon_url: SensitiveUrl, | |
) -> impl std::future::Future<Output = ()> { | |
pub async fn set_mock_builder(&mut self, beacon_url: SensitiveUrl) { |
and bellow call mock_builder_server.await
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.
true! updated
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.
impl Future
actually implicitly has a 'static
lifetime, and switching to async
changes this, so had to change it back
@@ -193,7 +180,7 @@ impl<E: EthSpec> MockBuilder<E> { | |||
beacon_url: SensitiveUrl, | |||
spec: ChainSpec, | |||
executor: TaskExecutor, | |||
) -> (Self, MockBuilderServer) { | |||
) -> (Self, (SocketAddr, impl Future<Output = ()>)) { |
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.
same as above, we can just:
) -> (Self, (SocketAddr, impl Future<Output = ()>)) { | |
) -> (Self, SocketAddr) { |
if we change the signature of the function to async fn
and .await
on server
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.
We want to lazily evaluate the server
future though, after the socket address has been returned and used by the caller.
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.
Oh yea, this one I think we have to leave
bors r+ |
## Proposed Changes - only use LH types to avoid build issues - use warp instead of axum for the server to avoid importing the dep ## Additional Info - wondering if we can move the `execution_layer/test_utils` to its own crate and import it as a dev dependency - this would be made easier by separating out our engine API types into their own crate so we can use them in the test crate - or maybe we can look into using reth types for the engine api if they are in their own crate Co-authored-by: realbigsean <[email protected]>
Build failed: |
bors r+ |
## Proposed Changes - only use LH types to avoid build issues - use warp instead of axum for the server to avoid importing the dep ## Additional Info - wondering if we can move the `execution_layer/test_utils` to its own crate and import it as a dev dependency - this would be made easier by separating out our engine API types into their own crate so we can use them in the test crate - or maybe we can look into using reth types for the engine api if they are in their own crate Co-authored-by: realbigsean <[email protected]>
Build failed:
|
bors retry |
## Proposed Changes - only use LH types to avoid build issues - use warp instead of axum for the server to avoid importing the dep ## Additional Info - wondering if we can move the `execution_layer/test_utils` to its own crate and import it as a dev dependency - this would be made easier by separating out our engine API types into their own crate so we can use them in the test crate - or maybe we can look into using reth types for the engine api if they are in their own crate Co-authored-by: realbigsean <[email protected]>
Build failed: |
bors retry |
## Proposed Changes - only use LH types to avoid build issues - use warp instead of axum for the server to avoid importing the dep ## Additional Info - wondering if we can move the `execution_layer/test_utils` to its own crate and import it as a dev dependency - this would be made easier by separating out our engine API types into their own crate so we can use them in the test crate - or maybe we can look into using reth types for the engine api if they are in their own crate Co-authored-by: realbigsean <[email protected]>
Build failed: |
bors retry |
## Proposed Changes - only use LH types to avoid build issues - use warp instead of axum for the server to avoid importing the dep ## Additional Info - wondering if we can move the `execution_layer/test_utils` to its own crate and import it as a dev dependency - this would be made easier by separating out our engine API types into their own crate so we can use them in the test crate - or maybe we can look into using reth types for the engine api if they are in their own crate Co-authored-by: realbigsean <[email protected]>
Build failed: |
bors retry |
## Proposed Changes - only use LH types to avoid build issues - use warp instead of axum for the server to avoid importing the dep ## Additional Info - wondering if we can move the `execution_layer/test_utils` to its own crate and import it as a dev dependency - this would be made easier by separating out our engine API types into their own crate so we can use them in the test crate - or maybe we can look into using reth types for the engine api if they are in their own crate Co-authored-by: realbigsean <[email protected]>
Pull request successfully merged into unstable. Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page.
|
## Proposed Changes - only use LH types to avoid build issues - use warp instead of axum for the server to avoid importing the dep ## Additional Info - wondering if we can move the `execution_layer/test_utils` to its own crate and import it as a dev dependency - this would be made easier by separating out our engine API types into their own crate so we can use them in the test crate - or maybe we can look into using reth types for the engine api if they are in their own crate Co-authored-by: realbigsean <[email protected]>
- only use LH types to avoid build issues - use warp instead of axum for the server to avoid importing the dep - wondering if we can move the `execution_layer/test_utils` to its own crate and import it as a dev dependency - this would be made easier by separating out our engine API types into their own crate so we can use them in the test crate - or maybe we can look into using reth types for the engine api if they are in their own crate Co-authored-by: realbigsean <[email protected]>
- only use LH types to avoid build issues - use warp instead of axum for the server to avoid importing the dep - wondering if we can move the `execution_layer/test_utils` to its own crate and import it as a dev dependency - this would be made easier by separating out our engine API types into their own crate so we can use them in the test crate - or maybe we can look into using reth types for the engine api if they are in their own crate Co-authored-by: realbigsean <[email protected]>
Proposed Changes
Additional Info
execution_layer/test_utils
to its own crate and import it as a dev dependency