Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
prestwich
left a comment
There was a problem hiding this comment.
looking good. do we have a plan to implement order filtering as stream combinators?
crates/orders/src/fee_policy.rs
Outdated
| N::TxEnvelope: Encodable2718, | ||
| { | ||
| tx_request = tx_request.with_from(signer_address); | ||
| let sendable = provider.fill(tx_request).await.map_err(FeePolicyError::FillTransaction)?; |
There was a problem hiding this comment.
we will need to document that nonce-management can be tricky and configuring the provider to increment nonces correctly across N transactions (potentially in several bundles) may be an issue
we may need custom checkpointing nonce-management so that fillers can parallelize, and revert to pre-fill states
There was a problem hiding this comment.
I'll add a note to the FeePolicySubmitter doc comments for now. This also seems like it's worth a follow-up ticket?
There was a problem hiding this comment.
go ahead and make a followup in idea status :)
That also sounds like a good candidate for a follow-up ticket. |
crates/orders/src/fee_policy.rs
Outdated
| N::TxEnvelope: Encodable2718, | ||
| { | ||
| tx_request = tx_request.with_from(signer_address); | ||
| let sendable = provider.fill(tx_request).await.map_err(FeePolicyError::FillTransaction)?; |
There was a problem hiding this comment.
go ahead and make a followup in idea status :)
Ticketed here. |
728b419 to
43e9260
Compare

This implements the
Fillerand theFeePolicySubmitterto support creating and submitting fills.I leaned heavily on the current implementation in the signet-orders repo here.
This diverges from that impl in the following ways:
GasFillerin order to have these values auto-calculated. Alternatively, I could add hard-coded defaults as per the other crate's approach. Or, possibly a combination, whereFillerOptionscould have optional defaults for these, and if these areNonethen theGasFillermust have been configured.A further minor point is that I'm unsure if there's an opportunity for optimisation by parallelising calls to
sign_and_encode_tx. However, I'm concerned that doing this could potentially cause problems with nonce assignment.