-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Create uninitialized task for v1 gas price service #2442
base: feature/allow-DA-blocks-to-be-received-out-of-order
Are you sure you want to change the base?
Create uninitialized task for v1 gas price service #2442
Conversation
…to feature/init-task-for-v1-gas-price-service
…to feature/init-task-for-v1-gas-price-service
…to feature/init-task-for-v1-gas-price-service
…to feature/init-task-for-v1-gas-price-service
DA: DaBlockCostsSource, | ||
SettingsProvider: GasPriceSettingsProvider, | ||
{ | ||
const NAME: &'static str = "GasPriceServiceV0"; |
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.
const NAME: &'static str = "GasPriceServiceV0"; | |
const NAME: &'static str = "GasPriceServiceV1"; |
pub fn initialize_algorithm<Metadata>( | ||
config: &V1AlgorithmConfig, | ||
latest_block_height: u32, | ||
metadata_storage: &Metadata, | ||
) -> GasPriceResult<(AlgorithmUpdaterV1, SharedV1Algorithm)> | ||
where | ||
Metadata: MetadataStorage, | ||
{ | ||
let algorithm_updater; | ||
if let Some(updater_metadata) = metadata_storage | ||
.get_metadata(&latest_block_height.into()) | ||
.map_err(|err| GasPriceError::CouldNotInitUpdater(anyhow::anyhow!(err)))? | ||
{ | ||
let previous_metadata: V1Metadata = updater_metadata.try_into()?; | ||
algorithm_updater = v1_algorithm_from_metadata(previous_metadata, config); | ||
} else { | ||
algorithm_updater = config.into(); | ||
} | ||
|
||
let shared_algo = | ||
SharedGasPriceAlgo::new_with_algorithm(algorithm_updater.algorithm()); | ||
|
||
Ok((algorithm_updater, shared_algo)) | ||
} |
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.
i think this is a dupe of initialize_algorithm
from the v1/service.rs file, right?
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.
There is also the case where we have unrecorded blocks in the metadata that the committer has already reported. In that case we might want to recursively ask for batches of our smallest heights. The problem is we can't be sure we've got all the correct batches since the lowest height might be skipped. |
config: V1AlgorithmConfig, | ||
genesis_block_height: BlockHeight, | ||
settings: SettingsProvider, | ||
block_stream: BoxStream<SharedImportResult>, |
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.
Do we need to box this stream? Can't we just be generic over the stream here to be more flexible for e.g. tests?
}; | ||
use fuel_gas_price_algorithm::v1::AlgorithmUpdaterV1; | ||
|
||
pub struct UninitializedTask< |
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.
I'm not following why we need a separate UninitializedTask
. As I read this, the purpose of this type is to separate task creation (UninitializedTask::new
) and initialization UninitializedTask::init
. I don't see any extra information being provided during initialization, so what's the benefit of doing this over having a single function that returns GasPriceServiceV1
directly?
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.
Resolved offline.
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.
Summary: The initialization logic depends on database concepts (getting blocks at different heights etc.) that we don't want the gas price algo to be aware of, to maintain a good separation between domain and integration logic. Ideally this initialization logic shouldn't even be here but rather closer to the fuel-core code that starts the services, but for the time being it's better to keep it isolated to this particular task.
…to feature/init-task-for-v1-gas-price-service
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 good to me 👍
let start = read_algo.next_gas_price(); | ||
let mut watcher = StateWatcher::started(); |
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.
is there a reason this isn't StateWatcher::default()
?
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.
There were some places that process_l2_block_res
wasn't getting called because of get_l2_block
yielding a result, but because the service was shutting down (and we always check if there is an l2 block available before shutting down).
I added the started
in a few places that it was shutting down early.
That being said, this isn't doing what the test says it's doing next__new_l2_block_saves_old_metadata
. It's checking the gas price:
// then
let new = read_algo.next_gas_price();
assert_ne!(start, new);
So I'll fix that.
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.
Fixed.
@@ -141,13 +141,15 @@ where | |||
Metadata: MetadataStorage, | |||
{ | |||
async fn run(&mut self, watcher: &mut StateWatcher) -> TaskNextAction { | |||
tracing::debug!("Starting gas price service"); |
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 might not want to log a "sunny day" events on the debug!
level. Please consider using trace!
.
Reference: this comment (and a couple of other comments in the linked PR).
Linked Issues/PRs
part of #2140
Description
Adding the
UninitializedTask
with minimum test coverage.Because of how we are organizing #2415, I don't believe we need to do any syncing of the DA Cost service before startup. If it's "behind" somehow, then the old values it provides will just be ignored. It might result in a little error in the profit value early on, but it will get washed out pretty quickly.
Checklist
Before requesting review
After merging, notify other teams
[Add or remove entries as needed]