-
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
chore(gas_price_service): define port for GasPriceDatabase #2226
Conversation
588fa87
to
a0a97e8
Compare
352cd0b
to
100fee8
Compare
ed1ad85
to
97b1cf0
Compare
100fee8
to
d45a323
Compare
97b1cf0
to
4096322
Compare
4096322
to
5702371
Compare
...ces/gas_price_service/src/fuel_gas_price_updater/fuel_core_storage_adapter/metadata_tests.rs
Outdated
Show resolved
Hide resolved
...ces/gas_price_service/src/fuel_gas_price_updater/fuel_core_storage_adapter/metadata_tests.rs
Outdated
Show resolved
Hide resolved
I guess this is still in draft. So maybe shouldn't have improved, but since this is all being done incrementally... I'm good with what I'm seeing. |
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. Just two todos that are missing a reference to an issue.
...ces/gas_price_service/src/fuel_gas_price_updater/fuel_core_storage_adapter/metadata_tests.rs
Outdated
Show resolved
Hide resolved
...ces/gas_price_service/src/fuel_gas_price_updater/fuel_core_storage_adapter/metadata_tests.rs
Outdated
Show resolved
Hide resolved
@@ -51,41 +34,6 @@ mod l2_source_tests; | |||
|
|||
pub mod storage; | |||
|
|||
impl<Storage> MetadataStorage for StructuredStorage<Storage> |
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.
The main idea of this code was that gas price crate defined default implementation of the MetadataStorage
port. I don't see why we don't want to follow that idea=)
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.
Having default implementation allows us test it within this crate, and inherit it later in the fuel-core
, if we want to, of course=)
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.
retained in 100b5b8
HistoricalView::latest_height(self) | ||
} | ||
|
||
fn rollback_last_block(&self) -> StorageResult<()> { |
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 we don't need to leak this kind of functionality to the service.
I think it would be better if FuelService
were responsible for database integrity. It is okay if other databases are behind than on-chain database. It is the responsibility of the service to catch up(since only the service knows how to advance the state). But if the on-chain database is behind other databases, then FuelService
should roll back them since only FuelService
knows that the database supports the state rewind feature.
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.
Hmmmm. Kinda confused. InitializationTask
currently handles that and I thought we wanted to get rid of it and move that code into GasPriceService
.
I think @xgreenx right that it's leaking something, but at the same time we have to leak the idea that they can be out of sync to include the syncing logic into GasPriceService
.
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.e. I'm not sure how the FuelService
could handle it without accessing the metadata and updater code.
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 @xgreenx here means that the FuelService
should be aware of rollback strategy for each of the db's included within CombinedDatabase
, which isn't that complex at the moment where we're leaking business logic, its just rolling back to the same height as the OnChainDb
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.
addressed in 9575a21
seems cleaner than before :)
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.
slightly unsure about where you'd like to place the rewind/rollback call ~ i've placed it before the init_sub_services
call :)
2735d80
to
100b5b8
Compare
fn set_metadata(&mut self, metadata: &UpdaterMetadata) -> Result<()>; | ||
} | ||
|
||
pub trait GasPriceData: Send + Sync { |
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.
the name of the port is GasPriceData
, but its only function returns a BlockHeight
.
Would it be possible to have a comment that explains how the two are related?
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.
addressed in d51d494
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.
The gas_price_service
crate doesn't know about the Database<GasPriceDatabase>
=)
The comment and name of the trait should be more clear regarding what expectation to the type that implements it, and maybe some description why
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.
clearer in 64818a6
} | ||
|
||
Ok(()) | ||
} | ||
|
||
fn revert_gas_price_db_to_height( |
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.
why is this fragment of code removed? Is it related to the temporary fix in combined_database.rs
?
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.
yes we don't need this code anymore since we delegate rolling back of db to FuelService
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.
Sometimes it's hard to know what I should give feedback on or just accept as a stopgap. With that in mind, I don't see any immediate need to hold this up.
S: ShutdownListener, | ||
{ | ||
if let Some(on_chain_height) = self.on_chain().latest_height_from_metadata()? { | ||
// todo(https://github.com/FuelLabs/fuel-core/issues/2239): This is a temporary fix |
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.
Yeah. We definitely want to throw an error if this fails.
GasPriceStore: GasPriceData | ||
+ MetadataStorage | ||
+ KeyValueInspect<Column = GasPriceColumn> | ||
+ Modifiable, |
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 should be careful about these all being bound together. Obviously this is still in an intermediate state, so maybe goes without saying, but ultimately the different ports should be handled independently. If they are the same thing under the hood, that shouldn't be leaked to like this.
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 also don't know the reason for making it generic in this PR; I think we can do it later when we switch from the V0 to the V1 algorithm.
@@ -12,3 +16,13 @@ pub trait L2Data: Send + Sync { | |||
height: &BlockHeight, | |||
) -> StorageResult<Option<Block<Transaction>>>; | |||
} | |||
|
|||
pub trait MetadataStorage: Send + Sync { |
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.
Why do we want to move this trait here? I thought that each service(v0 and v1) would have its own ports. It is the same for storage traits as well.
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.
The metadata storage would remain the same since we discussed that we will keep it versioned 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.
It was up to you=D I was thinking that you will choose the approach with two different columns, since it is more flexible.
@@ -36,25 +30,6 @@ fn database() -> StorageTransaction<InMemoryStorage<GasPriceColumn>> { | |||
InMemoryStorage::default().into_transaction() | |||
} | |||
|
|||
#[tokio::test] | |||
async fn get_metadata__can_get_most_recent_version() { |
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.
Why do we want to remove this test?
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.
functionally the same as set_metadata__can_set_metadata
there's already asserts for getting the metadata in that test.
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.
No. They are testing different functions. It doesn't matter if they are redundant, the point isn't coverage. We should keep it.
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.
okay
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.
addressed in 62343d7
GasPriceStore: GasPriceData | ||
+ MetadataStorage | ||
+ KeyValueInspect<Column = GasPriceColumn> | ||
+ Modifiable, |
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 also don't know the reason for making it generic in this PR; I think we can do it later when we switch from the V0 to the V1 algorithm.
} | ||
} | ||
|
||
impl MetadataStorage for Database<GasPriceDatabase> { |
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.
Why do we want to duplicate the implementation here instead of deriving the blanket implementation from gas price service crate?
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.
addressed in 417459d
already merged into master |
…eUpdater type into GasPriceService (#2256) > [!WARNING] > 🚧🚧 This is PR 6/n in refactoring the gas price service. Now that the `algorithm_updater` is a part of `fuel-core-gas-price-service` we have squashed it into the `GasPriceService` using the `UninitializedTask` struct. We don't implement `RunnableService` *or* `RunnableTask` for the `UninitializedTask` struct, merely use it as a wrapper to generate the `GasPriceServiceV0` 🚧🚧 ## Linked Issues/PRs <!-- List of related issues/PRs --> - #2246 - #2245 - #2230 - #2226 - #2224 - #2192 ## Description <!-- List of detailed changes --> - created common module containing storage adapter, l2 block source and some updater metadata stuff (linked to storage) - created v0 module containing impl of GasPriceAlgorithm for AlgorithmV0, and V0metadata stuff - created v1 module containing impl of GasPriceAlgorithm for AlgorithmV1 & da block costs source (V1Metadata didn’t exist before so i didn’t create it) - fuel-gas-price-updater will be nuked, an UninitializedGasPriceServiceV(x) for each version that takes in all the args needed ```mermaid graph TD A["lib.rs (entry point)"] B[common] B1[utils] B2[storage] B3[l2_block_source] C[ports] D[v0] E[v1] F[v0/algorithm] G[v1/algorithm] H[v0/service] I[v1/da_source] J[v0/metadata] K[v1/service] L[v0/uninitialized] A --> B B --> B1 B --> B2 B --> B3 B --> C C --> D C --> E D --> F D --> H D --> J D --> L E --> G E --> I E --> K F --> H G --> I H --> J J --> L L --> M[SharedV0Algorithm] L --> N[GasPriceServiceV0] subgraph Common B B1 B2 B3 end subgraph Ports C end subgraph V0 D F H J L end subgraph V1 E G I K end ``` ## Checklist - [x] Breaking changes are clearly marked as such in the PR description and changelog - [x] New behavior is reflected in tests - [x] [The specification](https://github.com/FuelLabs/fuel-specs/) matches the implemented behavior (link update PR if changes are needed) ### Before requesting review - [x] 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](https://github.com/FuelLabs/fuels-rs/) - [ ] [Sway compiler](https://github.com/FuelLabs/sway/) - [ ] [Platform documentation](https://github.com/FuelLabs/devrel-requests/issues/new?assignees=&labels=new+request&projects=&template=NEW-REQUEST.yml&title=%5BRequest%5D%3A+) (for out-of-organization contributors, the person merging the PR will do this) - [ ] Someone else? ---------
Note
This is PR 2/n in cleaning up the gas price service. This PR is first of few that moves the
algorithm_updater
from thesub_services
module offuel-core
tofuel-core-gas-price-service
.Please review #2224 before getting to this one ;)
Linked Issues/PRs
Description
Checklist
Before requesting review
After merging, notify other teams
[Add or remove entries as needed]