Create uninitialized task for v1 gas price service #2442

MitchTurner · 2024-11-18T04:05:24Z

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

Breaking changes are clearly marked as such in the PR description and changelog
New behavior is reflected in tests
The specification matches the implemented behavior (link update PR if changes are needed)

Before requesting review

I have reviewed the code myself
I have created follow-up issues caused by this PR and linked them here

After merging, notify other teams

[Add or remove entries as needed]

Rust SDK
Sway compiler
Platform documentation (for out-of-organization contributors, the person merging the PR will do this)
Someone else?

…-of-order

…data_tests.rs Co-authored-by: Rafał Chabowski <88321181+rafal-ch@users.noreply.github.com>

…-of-order

…-be-received-out-of-order

…-of-order

…to feature/init-task-for-v1-gas-price-service

…-of-order

netrome

Looks good to me 👍

rymnc · 2024-11-20T19:16:13Z

crates/services/gas_price_service/src/v0/tests.rs

    let start = read_algo.next_gas_price();
+    let mut watcher = StateWatcher::started();


is there a reason this isn't StateWatcher::default()?

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.

rafal-ch · 2024-11-26T14:35:01Z

crates/services/gas_price_service/src/v0/service.rs

@@ -141,13 +141,15 @@ where
    Metadata: MetadataStorage,
 {
    async fn run(&mut self, watcher: &mut StateWatcher) -> TaskNextAction {
+        tracing::debug!("Starting gas price service");


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).

rymnc

LGTM

The base branch was changed.

…as-price-service

crates/services/gas_price_service/src/v0/service.rs

xgreenx · 2024-12-03T02:29:52Z

crates/services/gas_price_service/src/v1/metadata.rs

@@ -92,7 +92,9 @@ impl From<&V1AlgorithmConfig> for AlgorithmUpdaterV1 {
            .map(|size| u128::from(*size))
            .sum();
        Self {
-            new_scaled_exec_price: value.new_exec_gas_price,
+            new_scaled_exec_price: value


Why do we multiple by the gas_price_factor here? And what is gas_price_factor? I don't see where this value comes from and it is not clear what is the purpose of it.

The gas_price_factor is just a scaling factor to make sure we can track the change between small values. Like we do for gas costs. If the gas price is 1, it is stored as 100 as the scaled value, then we can increase it by 10% or 5% under the hood but it will still be returned as 1 until it crosses 150 or whatever.

The gas price factor can be different on different heights. Do we take it into account?

I though we work with Wei and because of that we don't need to scale gas price.

What if the price is 1 Wei, which it often is? Possibly less so in the future, but still.

I'll add a test.

I added a TODO to remove this with this issue:
#2481

It would be better if you added todo for the field of the config instead of here=)

I'll move it in my next pr. Gonna merge.

Moved here:
abf0cca