feat(resharding): flat storage resharding mvp #12164

Trisfald · 2024-09-27T13:53:24Z

The PR adds early MVP capabilities of resharding flat storage (V3).

Main addition is FlatStorageResharder and all the toolings around that. Also, you can see traces of an early attempt to tie-in the resharder to existing flat storage code, mainly the flat storage creator.

FlatStorageResharder takes care of everything related to resharding the flat storage.
- Its running tasks can be interrupted by the a controller (integrated with existing resharding handle)
- Uses the concept of a scheduler to run tasks in the background
ReshardingEventType is an utility enum to represent types of resharding. There's one for now, but it makes easier adding more.

Achievements

Preparing flat storage's content for children after a shard split, for account-id based keys only.
Deletion of parent flat storage

Missing pieces

Catchup phase for children and creation of proper flat storage
Handling more complex key-values (not account-id based)
Integration with resharding manager and flat storage creator
Additional tests
Metrics

Missing pieces will likely be done in another PR.

EDIT: integrated with ShardLayoutV2, fixed all unit tests, re-arranged description.

…ding

Trisfald · 2024-09-27T13:54:30Z

chain/client/src/client.rs

@@ -176,6 +177,8 @@ pub struct Client {
    /// Cached precomputed set of TIER1 accounts.
    /// See send_network_chain_info().
    tier1_accounts_cache: Option<(EpochId, Arc<AccountKeys>)>,
+    /// Takes care of performing resharding on the flat storage.
+    pub flat_storage_resharder: FlatStorageResharder,


This may be moved inside the resharder manager @shreyan-gupta

Yeah, agree if it's simple enough

Trisfald · 2024-09-27T13:56:12Z

core/store/src/flat/types.rs

+    /// UId of the right child shard. Will contain everything greater or equal than boundary account.
+    pub right_child_shard: ShardUId,
+    /// The new shard layout.
+    pub shard_layout: ShardLayout,


I was on the fence about storing shard_layout here, but it makes things so much more self-contained in FlatStorageResharder and testing easier as well.

Trisfald · 2024-09-27T13:57:37Z

chain/chain/src/flat_storage_resharder.rs

+    /// * `block_hash`: block hash of the block in which the split happens
+    /// * `scheduler`: component used to schedule the background tasks
+    /// * `controller`: manages the execution of the background tasks
+    pub fn start_resharding_from_new_shard_layout(


API can be improved if event_type_from_shard_layout or an equivalent is moved into the resharding manager

Trisfald · 2024-09-27T13:59:19Z

chain/chain/src/flat_storage_resharder.rs

+
+/// Struct used to destructure a new shard layout definition into the resulting resharding event.
+#[cfg_attr(test, derive(PartialEq, Eq))]
+enum ReshardingEventType {


I've found this object useful to convey the essence of the resharding event. Yes, only Split is available.. for now

Maybe this and event_type_from_shard_layout could be moved in the resharding manager as they aren't really flat storage specific @shreyan-gupta

On one hand side I love the idea. On the other hand I feel like that it only makes sense if we do it everywhere. It would be strange to have it in flat storage but not in memtrie etc. I'm undecided so I'll leave it to you ;)

Trisfald · 2024-09-27T14:00:56Z

chain/chain/src/flat_storage_resharder.rs

+/// Helps control the flat storage resharder operation. More specifically,
+/// it has a way to know when the background task is done or to interrupt it.
+#[derive(Clone)]
+pub struct FlatStorageResharderController {


Extends ReshardingHandle with notification capability. If it doesn't prove useful it can be easily be swapped with the handle directly

Trisfald · 2024-09-27T14:01:57Z

chain/chain/src/flat_storage_resharder.rs

+}
+
+/// Represent the capability of scheduling the background tasks spawned by flat storage resharding.
+pub trait FlatStorageResharderScheduler {


I came up with this trait to abstract the task scheduling. It works well in tests, I hope it can be plugged nicely with actors or whatever else we will end up using.

Just grepping for the "scheduler" keyword it seems that those are typically Senders e.g.:

state_parts_task_scheduler: &Sender<ApplyStatePartsRequest>, load_memtrie_scheduler: &Sender<LoadMemtrieRequest>, block_catch_up_task_scheduler: &Sender<BlockCatchUpRequest>,

This API should work out of the box in TestLoop

…ding

codecov · 2024-10-01T10:13:59Z

Codecov Report

Attention: Patch coverage is 86.96774% with 101 lines in your changes missing coverage. Please review.

Project coverage is 71.83%. Comparing base (0c135f2) to head (4468660).
Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
chain/chain/src/flat_storage_resharder.rs	87.82%	58 Missing and 18 partials ⚠️
chain/chain/src/resharding/event_type.rs	92.70%	7 Missing ⚠️
chain/chain/src/flat_storage_creator.rs	33.33%	6 Missing ⚠️
core/primitives/src/shard_layout.rs	72.22%	5 Missing ⚠️
core/store/src/flat/types.rs	33.33%	4 Missing ⚠️
chain/chain/src/resharding/manager.rs	75.00%	1 Missing and 1 partial ⚠️
chain/chain-primitives/src/error.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #12164      +/-   ##
==========================================
+ Coverage   71.76%   71.83%   +0.07%     
==========================================
  Files         825      827       +2     
  Lines      165868   166626     +758     
  Branches   165868   166626     +758     
==========================================
+ Hits       119028   119700     +672     
- Misses      41647    41716      +69     
- Partials     5193     5210      +17

Flag	Coverage Δ
backward-compatibility	`0.17% <0.00%> (-0.01%)`	⬇️
db-migration	`0.17% <0.00%> (-0.01%)`	⬇️
genesis-check	`1.25% <0.00%> (-0.01%)`	⬇️
integration-tests	`38.78% <8.38%> (-0.16%)`	⬇️
linux	`71.51% <86.19%> (+0.07%)`	⬆️
linux-nightly	`71.42% <86.96%> (+0.07%)`	⬆️
macos	`54.52% <86.06%> (+0.11%)`	⬆️
pytests	`1.57% <0.00%> (-0.01%)`	⬇️
sanity-checks	`1.37% <0.00%> (-0.01%)`	⬇️
unittests	`65.65% <86.06%> (+0.10%)`	⬆️
upgradability	`0.21% <0.00%> (-0.01%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

wacban

LGTM, great stuff!

I left a few comments but nothing major. I'll have another look and approve once it all settles in my head.

chain/chain/src/flat_storage_resharder.rs

wacban · 2024-10-01T09:53:39Z

chain/chain/src/flat_storage_creator.rs

+                    // TODO(Trisfald): call resume
+                    // flat_storage_resharder.resume(shard_uid, &status, ...)?;


Is this a todo for this PR or later? I'm fine with later but I just saw that the resume method is already implemented so might as well call it.

It is meant for a second PR, I'll need to see how to link everything together

wacban · 2024-10-01T09:55:53Z

chain/chain/src/flat_storage_resharder.rs

+}
+
+/// Represent the capability of scheduling the background tasks spawned by flat storage resharding.
+pub trait FlatStorageResharderScheduler {


Just grepping for the "scheduler" keyword it seems that those are typically Senders e.g.:

state_parts_task_scheduler: &Sender<ApplyStatePartsRequest>, load_memtrie_scheduler: &Sender<LoadMemtrieRequest>, block_catch_up_task_scheduler: &Sender<BlockCatchUpRequest>,

This API should work out of the box in TestLoop

wacban · 2024-10-01T11:38:45Z

chain/chain/src/flat_storage_resharder.rs

+
+/// Struct used to destructure a new shard layout definition into the resulting resharding event.
+#[cfg_attr(test, derive(PartialEq, Eq))]
+enum ReshardingEventType {


On one hand side I love the idea. On the other hand I feel like that it only makes sense if we do it everywhere. It would be strange to have it in flat storage but not in memtrie etc. I'm undecided so I'll leave it to you ;)

wacban · 2024-10-01T11:40:11Z

chain/chain/src/flat_storage_resharder.rs

+
+#[derive(Debug)]
+#[cfg_attr(test, derive(PartialEq, Eq))]
+struct ReshardingSplitParams {


I'm a bit surprised that the boundary account is not part of it. Do you get it from elsewhere?

ReshardingSplitParams is the output of processing the shard layout and the latter has already the boundary. Well, conceptually it would be nice to have the boundary in ReshardingSplitParams (I started with that), but I found the boundary to be pretty useless on its own: one needs the shard layout and the account-id to get the destination shard.

Looking at the split method, it takes the params and the shard layout. Would it make sense to shove the shard layout inside of the params? You can then get rid of left/ right child because they can be obtained from the shard layout.

chain/chain/src/flat_storage_resharder.rs

wacban · 2024-10-01T12:22:34Z

core/primitives/src/shard_layout.rs

+    BorshSerialize,
+    BorshDeserialize,


Why do you need borsh serialize and protocol schema?

Borsh because I'm storing ShardLayout inside the flat storage resharding status and ProtocolSchema as a consequence to make devs more aware of changes in serialization

There are alternatives such as retrieving ShardLayout from epoch manager. In such case I'd need to add a dependency on EpochManager in FlatStorageResharder.

Personally, borsh always scares me but we should be good since ShardLayout is already versioned

EpochManager is everywhere anywya so I wouldn't mind using it.

shreyan-gupta

I'm slightly unclear about how the flow of resharding the flat storage would look like exactly, like, how are the different components like flat storage creator, resharding manager, any potential actors, etc. working? We can discuss this during the offsite, or in the resharding meeting.

shreyan-gupta · 2024-10-02T01:57:00Z

core/primitives/src/shard_layout.rs

+    BorshSerialize,
+    BorshDeserialize,


Personally, borsh always scares me but we should be good since ShardLayout is already versioned

shreyan-gupta · 2024-10-02T02:01:20Z

core/store/src/flat/types.rs

+    CreatingChild,
+    /// We apply deltas from disk until the head reaches final head.
+    /// Includes block hash of flat storage head.
+    CatchingUp(CryptoHash),


Umm, I'm curious if we need a specific catching up phase or whether FlatStorage should automatically be able to handle this after unlocking?

It depends what we want to do

Option 1: do catchup phase for children and their flat storage will be created at chain head height or very close
Option 2: no catchup, create children at parent flat store height. This means the first block postprocessing has to go through quite a lot of deltas

Any opinions?

In option 2, would it happen in the main client thread? I don't think this would be a good idea.

I think option 2 is "rate limited" in implementation so should be fine if it simplifies code.
(Note: We may need to do catchup manually in case we are looking to load memtrie from flat storage; to be checked)

In that case I'm happy with either.

shreyan-gupta · 2024-10-02T02:08:30Z

core/store/src/adapter/flat_store.rs

@@ -266,6 +270,12 @@ impl<'a> FlatStoreUpdateAdapter<'a> {
        self.remove_range_by_shard_uid(shard_uid, DBCol::FlatStateDeltaMetadata);
    }

+    pub fn remove_flat_storage(&mut self, shard_uid: ShardUId) {


Could we fix the nomenclature a bit, remove_all and remove_flat_storage can get confusing

shreyan-gupta · 2024-10-02T06:06:47Z

chain/chain/src/flat_storage_resharder.rs

+        &self,
+        parent_shard: ShardUId,
+        status: &SplittingParentStatus,
+        scheduler: &dyn FlatStorageResharderScheduler,


nothing seems to implement FlatStorageResharderScheduler right now?

Yes for now it's used only in test

I could make this into a sender or have the actor impl FlatStorageResharderScheduler 🤔

shreyan-gupta · 2024-10-02T06:18:04Z

chain/chain/src/flat_storage_creator.rs

    pub fn new(
        epoch_manager: Arc<dyn EpochManagerAdapter>,
        runtime: Arc<dyn RuntimeAdapter>,
        chain_store: &ChainStore,
+        flat_storage_resharder: &FlatStorageResharder,


I didn't completely understand why is flat_storage_resharder a part of FlatStorageCreator? The FlatStorageCreator is created at the time of calling new() in client. The Self::create_flat_storage_for_current_epoch is also thus called only in the beginning right? How do we later set the status of some flat storage to FlatStorageStatus::Resharding?

Basically the FlatStorageResharder is part of client.

FlatStorageCreator uses a reference to the resharder to handle the case when the node restarts and flat storage resharding was in progress. I did like this because the creator already has logic to handle resuming flat storage from the previous state.

In normal flow the resharding of flat storage would be initiated by the resharding manager, but that part is not done yet

shreyan-gupta · 2024-10-02T06:21:46Z

chain/chain/src/flat_storage_resharder.rs

+    /// * `status`: resharding status of the shard
+    /// * `scheduler`: component used to schedule the background tasks
+    /// * `controller`: manages the execution of the background tasks
+    pub fn resume(


Could you remind me when is resume called and by who? Also, when is start_resharding_from_new_shard_layout called?

resume will be called by flat storage creator at node restart, if necessary

start_resharding_from_new_shard_layout will be called by resharding manager

shreyan-gupta · 2024-10-02T06:27:56Z

chain/chain/src/flat_storage_resharder.rs

+
+    // Prepare the store object for commits and the iterator over parent's flat storage.
+    let flat_store = resharder.runtime.store().flat_store();
+    let mut iter = flat_store.iter(parent_shard);


I think what Wac means here is that we need to check the following

Flat head is at height which is the first block of the new epoch with the new shard layout

Flat head is indeed locked/frozen

Btw, I don't think the assumption where we say flat head is same as chain head is true. Flat head when locked can be behind chain head.

shreyan-gupta · 2024-10-02T06:31:06Z

chain/chain/src/flat_storage_resharder.rs

+    store_update: &mut FlatStoreUpdateAdapter,
+    status: &SplittingParentStatus,
+) -> Result<(), std::io::Error> {
+    if key.is_empty() {


might as well just panic here, this should never ever ever happen.

shreyan-gupta · 2024-10-02T06:36:40Z

chain/chain/src/flat_storage_resharder.rs

+    value: FlatStateValue,
+    store_update: &mut FlatStoreUpdateAdapter,
+    account_id_parser: impl FnOnce(&[u8]) -> Result<AccountId, std::io::Error>,
+) -> Result<(), std::io::Error> {


unsure why are we using std::io::Error instead of a more concrete type like resharding error? If we really do want to use a generic error type, we can go for anyhow::Error here instead.

I used the error of parse_account_id_ functions, but I'm fine to use resharding error

shreyan-gupta · 2024-10-02T06:41:49Z

chain/chain/src/flat_storage_resharder.rs

+    /// A value of `true` means that the operation completed successfully.
+    completion_sender: Sender<FlatStorageReshardingTaskStatus>,
+    /// Corresponding receiver for `completion_sender`.
+    pub completion_receiver: Receiver<FlatStorageReshardingTaskStatus>,


Umm, why exactly would the FlatStorageResharderController hold the completion_receiver? Shouldn't that be sent to someone who is waiting for the call the resharding of flat storage to be finished? Someone in client?

Also, is this the patter we would like to follow? I thought the convention was to send actix messages once jobs were done? Btw, where is the job of flat storage resharding being done? As in, which actor is it a part of?

The idea was anyone interested could clone the controller or the receiver

The actor is not done yet. I planned to add that part in a second PR, maybe reusing a shared resharding actor. The actor anyway should be very a very thin layer, I hope.

Would we reload memtrie immediately after FS is ready or delay until node restart?

The current understanding is to do memtrie reload FS is ready. Not set in stone though

Trisfald · 2024-10-02T15:51:43Z

I did some refactoring aside from applying suggestions.

Main change is that now ReshardingEventType is independent from flat storage and has more elegant logic to detect a shard split. Also trying to use ReshardingEventType in resharding manager.

wacban · 2024-10-02T21:20:59Z

I did some refactoring aside from applying suggestions.

Main change is that now ReshardingEventType is independent from flat storage and has more elegant logic to detect a shard split. Also trying to use ReshardingEventType in resharding manager.

Cool, please re-request review once it's ready for review.

wacban · 2024-10-02T21:00:59Z

core/store/src/flat/types.rs

+#[derive(
+    BorshSerialize, BorshDeserialize, Clone, Debug, PartialEq, Eq, serde::Serialize, ProtocolSchema,
+)]
+pub struct SplittingParentStatus {


nit: It took me a while to figure out that this is to describe a status of a shard's flat storage rather than the status of resharding. Can you explain that in the comment please?

chain/chain/src/flat_storage_resharder.rs

wacban · 2024-10-02T21:04:53Z

chain/chain/src/flat_storage_resharder.rs

+            ..
+        } = split_params;
+        info!(target: "resharding", ?split_params, "initiating flat storage shard split");
+        self.check_no_resharding_in_progress()?;


not for this pr
Eventually we'd want to handle the case when there is a at the end of the epoch and resharding is triggered multiple times. In that case you may want to clean up everything and start over.

Yeah it could be done through by interrupting through ReshardingHandle or automatically depending on the block hash

wacban · 2024-10-02T21:10:12Z

chain/chain/src/flat_storage_resharder.rs

+
+#[derive(Debug)]
+#[cfg_attr(test, derive(PartialEq, Eq))]
+struct ReshardingSplitParams {


Looking at the split method, it takes the params and the shard layout. Would it make sense to shove the shard layout inside of the params? You can then get rid of left/ right child because they can be obtained from the shard layout.

wacban · 2024-10-02T21:13:41Z

chain/chain/src/flat_storage_resharder.rs

+        let flat_head = if let FlatStorageStatus::Ready(FlatStorageReadyStatus { flat_head }) =
+            store
+                .get_flat_storage_status(parent_shard)
+                .map_err(|err| Into::<StorageError>::into(err))?
+        {
+            flat_head
+        } else {
+            let err_msg = "flat storage parent shard is not ready!";
+            error!(target: "resharding", ?parent_shard, err_msg);
+            return Err(Error::ReshardingError(err_msg.to_owned()));
+        };


nit: Can you move it to a helper method and multi-line it a bit?

chain/chain/src/flat_storage_resharder.rs

wacban · 2024-10-02T21:18:16Z

chain/chain/src/flat_storage_resharder.rs

+
+/// Struct used to destructure a new shard layout definition into the resulting resharding event.
+#[derive(Debug)]
+#[cfg_attr(test, derive(PartialEq, Eq))]


Why do you need the conditional derive? Are those not used outside of tests for now?

Only in tests for now :)

wacban · 2024-10-02T21:22:31Z

core/primitives/src/shard_layout.rs

+    BorshSerialize,
+    BorshDeserialize,


EpochManager is everywhere anywya so I wouldn't mind using it.

wacban

LGTM, mostly just styling comments, for the rest feel free to follow up separately

chain/chain/src/flat_storage_creator.rs

chain/chain/src/flat_storage_resharder.rs

wacban · 2024-10-10T20:02:15Z

chain/chain/src/flat_storage_resharder.rs

+        Self { runtime, resharding_event }
+    }
+
+    /// Resumes a resharding event that was in progress.


nit: ... that was interrupted

It feels strange to be resuming something that is in progress.

Can you also add what can cause resharding to be halted and resumed? Is node restart / crashing the only event that may cause this?

Answering my own question - I think a fork may also cause interruption.

I made more clear the distinction between cancelling (to be used in the case forks) and interrupting (when the node crashes).

wacban · 2024-10-10T20:04:51Z

chain/chain/src/flat_storage_resharder.rs

+    ) -> Result<(), Error> {
+        match status {
+            FlatStorageReshardingStatus::CreatingChild => {
+                // Nothing to do here because the parent will take care of resuming work.


I wouldn't be surprised to see some cleanup logic here but it's also fine to do it from parent.

wacban · 2024-10-10T20:11:03Z

core/store/src/flat/types.rs

+#[derive(
+    BorshSerialize, BorshDeserialize, Clone, Debug, PartialEq, Eq, serde::Serialize, ProtocolSchema,
+)]
+pub enum FlatStorageReshardingStatus {


Thinking about the future, the next event that we'll be adding will be merging. Can you make the names of events future proof - e.g. think what will be good names for the merging parents and children and make it so that it's consistent when we add those.

I was thinking about MergingShards but it's still very far away concept in my mind

wacban · 2024-10-10T20:46:02Z

chain/chain/src/resharding/event_type.rs

+    /// Hash of the first block having the new shard layout.
+    pub block_hash: CryptoHash,


The hash of the first block with new shard layout is not known at the time when the flat storage resharding is triggered (unless maybe I'm missing something). My thinking was that this will be triggered together with all of the rest of resharding logic in post process of the last block of old shard layout.

I'll revisit this comment in a following PR!

wacban · 2024-10-10T20:47:22Z

chain/chain/src/resharding/event_type.rs

+                    }
+                    // Parent shard is no longer part of this shard layout.
+                    let parent_shard =
+                        ShardUId { version: shard_layout.version(), shard_id: *parent_id as u32 };


We're relying here on the version not changing starting from the ShardLayoutV2. Just saying because it looked sus at first.

Yeah indeed

wacban · 2024-10-10T20:48:16Z

chain/chain/src/resharding/event_type.rs

+                    // Find the boundary account between the two children.
+                    let Some(boundary_account_index) =
+                        shard_layout.shard_ids().position(|id| id == left_child_shard.shard_id())


nit: I would move that to shard layout method.
maybe even the entire method
fine to do later

wacban · 2024-10-10T20:50:58Z

chain/chain/src/resharding/manager.rs

            return Ok(());
        }
-        assert_eq!(children_shard_uids.len(), 2);
+        let Ok(Some(ReshardingEventType::SplitShard(split_shard_event))) = resharding_event_type


You are not handling the error case here - Err and Ok(None) are treated the same.

if intentional - please comment

if accidental - please add ? or handle it explicitly

core/primitives/src/shard_layout.rs

…ding

Trisfald added 12 commits September 19, 2024 10:59

fix typo

51f9f44

skeleton for flat storage resharding V3 update

eb421de

skeleton of flat storage resharder

c1a71a6

add TODO details

9234160

add API stub to resume or start resharding of flat storage

c39b476

flat storage resharding start fn

f977326

many improvements

d6823d3

add test

0195907

improve resharder api

c7a6875

Merge remote-tracking branch 'origin/master' into flat-storage-reshar…

4c7e9b2

…ding

use the new flat store adapter

79730a4

implement simple key value copy

ad83e0b

Trisfald commented Sep 27, 2024

View reviewed changes

Trisfald added 6 commits September 30, 2024 11:53

add implemnetation of flat storage resharding interrupt

ae82453

change tests setup to use a test chain

e735755

handle more DB columns

fc38090

improve comments

75c42b5

Merge remote-tracking branch 'origin/master' into flat-storage-reshar…

3848c40

…ding

fix unit tests

306c502

Trisfald marked this pull request as ready for review September 30, 2024 15:08

Trisfald requested a review from a team as a code owner September 30, 2024 15:08

Trisfald requested review from wacban and shreyan-gupta September 30, 2024 15:08

Trisfald added 2 commits October 1, 2024 11:31

add parent shard deletion in task

b9f11d4

update protocol schema

7fe014e

wacban reviewed Oct 1, 2024

View reviewed changes

Trisfald added 6 commits October 1, 2024 14:49

multi line imports

f45cc9e

apply code review suggestions

3c188c5

add note about parent shard flat storage invariant

ac6d642

add test reject_split_shard_if_parent_is_not_ready

9269c37

use a dedicated type to represent task statuses

7ad602e

refactor copy_kv_to_child into a free function

d0b3125

shreyan-gupta reviewed Oct 2, 2024

View reviewed changes

Trisfald added 2 commits October 2, 2024 11:39

address code review comments

df869fc

refactor ReshardingEventType

e1f3b5d

update protocol schema

6d4188c

wacban reviewed Oct 2, 2024

View reviewed changes

Trisfald added 2 commits October 3, 2024 10:57

improve code clarity

d6b5ab3

remove FlatStorageResharderInner

c52b947

Trisfald requested a review from wacban October 3, 2024 09:39

wacban approved these changes Oct 10, 2024

View reviewed changes

Trisfald added 6 commits October 14, 2024 10:50

Merge remote-tracking branch 'origin/master' into flat-storage-reshar…

f542962

…ding

formatting

7670129

code review improvements

a3849a2

propagate error

17538f9

make get_parent_shard_and_status a resharder function

ebd144a

update protocol schema

4468660

Trisfald added this pull request to the merge queue Oct 14, 2024

Merged via the queue into near:master with commit 04eb2c7 Oct 14, 2024
29 of 30 checks passed

Trisfald deleted the flat-storage-resharding branch October 14, 2024 11:04

Trisfald mentioned this pull request Oct 14, 2024

[Tracking Issue] Flat storage for resharding V3 #12174

Closed

33 tasks

		// TODO(Trisfald): call resume
		// flat_storage_resharder.resume(shard_uid, &status, ...)?;

		/// Hash of the first block having the new shard layout.
		pub block_hash: CryptoHash,

feat(resharding): flat storage resharding mvp #12164

feat(resharding): flat storage resharding mvp #12164

Conversation

Trisfald commented Sep 27, 2024 • edited Loading

Achievements

Missing pieces

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Trisfald Sep 27, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov bot commented Oct 1, 2024 • edited Loading

Codecov Report

wacban left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

shreyan-gupta left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Trisfald commented Oct 2, 2024

wacban commented Oct 2, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wacban left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Trisfald commented Sep 27, 2024 •

edited

Loading

Trisfald Sep 27, 2024 •

edited

Loading

codecov bot commented Oct 1, 2024 •

edited

Loading