Conversation
klkvr
requested review from
Rjected,
fgimenez,
gakonst,
mattsse,
mediocregopher,
rkrasiuk,
shekhirin and
yongkangc
as code owners
klkvr
force-pushed
the
klkvr/custom-stages
branch
3 times, most recently
from
e208eff to
4efc99a
Compare
Base automatically changed from
klkvr/check-consistency-custom-stages
to
main
October 14, 2025 16:36
klkvr
force-pushed
the
klkvr/custom-stages
branch
from
f16a014 to
e4e3150
Compare
mattsse
requested changes
Oct 15, 2025
Collaborator
mattsse
left a comment
mattsse
left a comment
There was a problem hiding this comment.
makes sense
I think invoking the stages after saving blocks make sense, I guess we could also introduce another trait for this that extend stage so that we can directly provide the new blocks but for now this seems easier
Comment on lines
+208
to
+213
| /// Returns additional stages to be added to the pipeline. | ||
| fn extra_stages( | ||
| &self, | ||
| ) -> Vec<BoxedStage<<N::Provider as DatabaseProviderFactory>::ProviderRW>> { | ||
| Vec::new() | ||
| } |
Collaborator
There was a problem hiding this comment.
this makes sense here I believe
| exex_manager_handle, | ||
| )), | ||
| )) | ||
| .add_stages_before(extra_stages, StageId::Finish), |
Collaborator
There was a problem hiding this comment.
I think we're fine if these are put before finish stage
|
|
||
| provider_rw.save_blocks(blocks)?; | ||
|
|
||
| for stage in &mut self.custom_stages { |
Collaborator
There was a problem hiding this comment.
can we document here that we need invoke those after we save the blocks, because we want them to run last
Collaborator
|
@klkvr do you still want this? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Based on #18955
Allows defining custom stages on
NodeAddOns. Those stages are added to pipeline and advanced inPersistenceService.Open questions:
custom_stagesgetter? MaybeNodetrait?PersistenceService? This should work fine for most of the cases, especially for custom indexes. Another approach would be allowing to define custom hooks invoked when persisting but it feels like this might just lead to redundancy in custom stage impls