Stage clob pair creation side effect #2443
Conversation
WalkthroughThe changes introduce a new Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (7)
- protocol/finalizeblock/event_stager.go (1 hunks)
- protocol/streaming/full_node_streaming_manager.go (6 hunks)
- protocol/streaming/noop_streaming_manager.go (0 hunks)
- protocol/streaming/types/interface.go (0 hunks)
- protocol/x/clob/types/expected_keepers.go (0 hunks)
- protocol/x/subaccounts/keeper/subaccount.go (0 hunks)
- protocol/x/subaccounts/types/types.go (0 hunks)
💤 Files with no reviewable changes (5)
- protocol/streaming/noop_streaming_manager.go
- protocol/streaming/types/interface.go
- protocol/x/clob/types/expected_keepers.go
- protocol/x/subaccounts/keeper/subaccount.go
- protocol/x/subaccounts/types/types.go
🔇 Additional comments (9)
protocol/finalizeblock/event_stager.go (3)
43-44: Verify the use of an infinite gas meter in context.The use of
ante_types.NewFreeInfiniteGasMeter()to create a context with an infinite gas meter may have unintended side effects or security implications. Please ensure that this approach is safe and does not introduce vulnerabilities or performance issues in the execution environment.
61-66: EnsurecountsByteshas the correct length before processing.When using
binary.BigEndian.Uint32(countsBytes), thecountsBytesslice must be at least 4 bytes long. If it's shorter, this will cause a panic. Verify thatcountsByteshas the expected length before attempting to convert it.Apply this diff to add a length check:
countsBytes := store.Get([]byte(s.stagedEventCountKey)) if countsBytes == nil { return 0 } +if len(countsBytes) < 4 { + // Handle the unexpected length appropriately + return 0 // or return an error if necessary +} return binary.BigEndian.Uint32(countsBytes)
73-74: Review the use of an infinite gas meter when staging events.Similar to the retrieval method, using
ante_types.NewFreeInfiniteGasMeter()inStageFinalizeBlockEventmay have unintended consequences. Please confirm that this is safe within the application's context and does not expose any risks.protocol/streaming/full_node_streaming_manager.go (6)
23-24: Importing thefinalizeblockpackageThe addition of the
finalizeblockimport is appropriate for utilizing theEventStagerfunctionality introduced in this PR.
66-66: AddingfinalizeBlockStagerto the structThe
finalizeBlockStagerfield is correctly added to theFullNodeStreamingManagerImplstruct to manage event staging.
124-129: InitializingfinalizeBlockStagercorrectlyThe
finalizeBlockStageris properly initialized usingfinalizeblock.NewEventStagerwith the correct parameters. This ensures that staged events are managed consistently.
408-410: Staging subaccount updatesThe
SendSubaccountUpdatemethod correctly stages subaccount update events usingfinalizeBlockStager.StageFinalizeBlockEvent. This aligns with the new event staging mechanism.
556-558: Staging orderbook updatesThe
SendOrderbookUpdatesmethod correctly stages orderbook update events usingfinalizeBlockStager.StageFinalizeBlockEvent. This modification aligns with the refactored event handling.
631-633: Staging orderbook fill eventsThe
SendOrderbookFillUpdatemethod appropriately stages orderbook fill events with thefinalizeBlockStager. This ensures that orderbook fills are handled in the finalized event flow.
|
|
||
| // Store events keyed by index. | ||
| store = prefix.NewStore(store, []byte(s.stagedEventKeyPrefix)) | ||
| store.Set(lib.Uint32ToKey(count), s.cdc.MustMarshal(stagedEvent)) |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Use Marshal instead of MustMarshal to handle errors gracefully.
Using s.cdc.MustMarshal(stagedEvent) will panic if marshaling fails. To improve error handling, consider using s.cdc.Marshal and managing any potential errors without causing a panic.
Apply this diff to handle marshaling errors:
-store.Set(lib.Uint32ToKey(count), s.cdc.MustMarshal(stagedEvent))
+bytes, err := s.cdc.Marshal(stagedEvent)
+if err != nil {
+ // Handle the error, such as logging or returning
+ return // or handle according to the application's error management strategy
+}
+store.Set(lib.Uint32ToKey(count), bytes)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| store.Set(lib.Uint32ToKey(count), s.cdc.MustMarshal(stagedEvent)) | |
| bytes, err := s.cdc.Marshal(stagedEvent) | |
| if err != nil { | |
| // Handle the error, such as logging or returning | |
| return // or handle according to the application's error management strategy | |
| } | |
| store.Set(lib.Uint32ToKey(count), bytes) |
| for i := uint32(0); i < count; i++ { | ||
| event := newStagedEvent() | ||
| bytes := store.Get(lib.Uint32ToKey(i)) | ||
| s.cdc.MustUnmarshal(bytes, event) |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Use Unmarshal instead of MustUnmarshal to handle errors gracefully.
The method s.cdc.MustUnmarshal(bytes, event) will panic if unmarshaling fails. To enhance robustness, it's advisable to handle unmarshaling errors explicitly using s.cdc.Unmarshal, allowing the program to manage errors without panicking.
Apply this diff to handle unmarshaling errors:
-s.cdc.MustUnmarshal(bytes, event)
+if err := s.cdc.Unmarshal(bytes, event); err != nil {
+ // Handle the error appropriately, such as logging it or returning it
+ continue // or break, return, etc., based on desired behavior
+}Committable suggestion was skipped due to low confidence.
| bytes := store.Get(lib.Uint32ToKey(i)) | ||
| s.cdc.MustUnmarshal(bytes, event) | ||
| events[i] = event |
There was a problem hiding this comment.
Handle potential nil values when retrieving events from the store.
When retrieving bytes with store.Get(lib.Uint32ToKey(i)), there's a possibility that the returned value is nil. Using s.cdc.MustUnmarshal(bytes, event) without checking may cause a panic if bytes is nil. Consider adding a nil check before unmarshaling to prevent potential runtime errors.
Apply this diff to handle nil values safely:
bytes := store.Get(lib.Uint32ToKey(i))
+if bytes == nil {
+ continue // or handle the nil case appropriately
+}
s.cdc.MustUnmarshal(bytes, event)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| bytes := store.Get(lib.Uint32ToKey(i)) | |
| s.cdc.MustUnmarshal(bytes, event) | |
| events[i] = event | |
| bytes := store.Get(lib.Uint32ToKey(i)) | |
| if bytes == nil { | |
| continue // or handle the nil case appropriately | |
| } | |
| s.cdc.MustUnmarshal(bytes, event) | |
| events[i] = event |
| store.Set([]byte(s.stagedEventCountKey), lib.Uint32ToKey(count+1)) | ||
|
|
||
| // Store events keyed by index. | ||
| store = prefix.NewStore(store, []byte(s.stagedEventKeyPrefix)) | ||
| store.Set(lib.Uint32ToKey(count), s.cdc.MustMarshal(stagedEvent)) |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Update the event count after successfully storing the event.
Currently, the event count is incremented before the event is stored. If an error occurs during store.Set for the event, the count would have been incremented inaccurately. Consider updating the event count only after the event has been successfully stored to maintain consistency.
Apply this diff to adjust the order of operations:
// Store events keyed by index.
store = prefix.NewStore(store, []byte(s.stagedEventKeyPrefix))
store.Set(lib.Uint32ToKey(count), s.cdc.MustMarshal(stagedEvent))
-// Increment events count.
-count := s.getStagedEventsCount(store)
-store.Set([]byte(s.stagedEventCountKey), lib.Uint32ToKey(count+1))
+
+// Increment events count after successful storage.
+store = noGasCtx.TransientStore(s.transientStoreKey)
+store.Set([]byte(s.stagedEventCountKey), lib.Uint32ToKey(count+1))Committable suggestion was skipped due to low confidence.
| events := sm.finalizeBlockStager.GetStagedFinalizeBlockEvents( | ||
| ctx, | ||
| func() *clobtypes.StagedFinalizeBlockEvent { | ||
| return &clobtypes.StagedFinalizeBlockEvent{} | ||
| }, | ||
| ) | ||
| results := make([]clobtypes.StagedFinalizeBlockEvent, len(events)) | ||
| for i, event := range events { | ||
| if event == nil { | ||
| panic("Got nil event from finalizeBlockStager") | ||
| } | ||
| results[i] = *event | ||
| } | ||
| return results |
There was a problem hiding this comment.
Avoid panicking when encountering nil events
The code currently panics if a nil event is retrieved from finalizeBlockStager, which can cause the node to crash unexpectedly. It's better to handle this scenario gracefully.
Consider logging the error and skipping the nil event:
for i, event := range events {
if event == nil {
- panic("Got nil event from finalizeBlockStager")
+ sm.logger.Error("Received nil event from finalizeBlockStager")
+ continue
}
results[i] = *event
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| events := sm.finalizeBlockStager.GetStagedFinalizeBlockEvents( | |
| ctx, | |
| func() *clobtypes.StagedFinalizeBlockEvent { | |
| return &clobtypes.StagedFinalizeBlockEvent{} | |
| }, | |
| ) | |
| results := make([]clobtypes.StagedFinalizeBlockEvent, len(events)) | |
| for i, event := range events { | |
| if event == nil { | |
| panic("Got nil event from finalizeBlockStager") | |
| } | |
| results[i] = *event | |
| } | |
| return results | |
| events := sm.finalizeBlockStager.GetStagedFinalizeBlockEvents( | |
| ctx, | |
| func() *clobtypes.StagedFinalizeBlockEvent { | |
| return &clobtypes.StagedFinalizeBlockEvent{} | |
| }, | |
| ) | |
| results := make([]clobtypes.StagedFinalizeBlockEvent, len(events)) | |
| for i, event := range events { | |
| if event == nil { | |
| sm.logger.Error("Received nil event from finalizeBlockStager") | |
| continue | |
| } | |
| results[i] = *event | |
| } | |
| return results |
teddyding
force-pushed
the
td/pml-stager
branch
from
ff9eb5f
to
3b92b79
Compare
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Outside diff range and nitpick comments (3)
proto/dydxprotocol/clob/finalize_block.proto (1)
8-13: LGTM: Well-structured message definition with room for expansion.The
ClobStagedFinalizeBlockEventmessage is well-defined:
- It uses a
oneoffield, allowing for future event types to be added easily.- The current event type
create_clob_pairis clearly named and typed.Consider expanding the comment to provide more context:
- // ClobStagedFinalizeBlockEvent defines a CLOB event staged during FinalizeBlock. + // ClobStagedFinalizeBlockEvent defines a CLOB (Central Limit Order Book) event + // staged during the FinalizeBlock step. It can contain various types of events, + // currently supporting the creation of a new CLOB pair.protocol/x/clob/abci.go (1)
Line range hint
1-301: Suggest additional testing and documentation for the new functionality.While the change to the
Precommitfunction is minimal and focused, it introduces new behavior in the ABCI lifecycle. To ensure robustness and maintainability:
- Add unit tests specifically for the
ProcessStagedFinalizeBlockEventsfunctionality in the context of thePrecommitfunction.- Update the module's documentation to reflect this new step in the ABCI lifecycle, explaining when and why staged events are processed.
- Consider adding logging or metrics to track the number and types of events processed during this step, which could be valuable for monitoring and debugging.
Would you like assistance in drafting test cases or documentation updates for this change?
protocol/x/clob/keeper/clob_pair.go (1)
207-207: Consider adding explanatory comment forlib.AssertDeliverTxMode(ctx)While the assertion ensures the context is in
DeliverTxmode, adding a comment explaining why this assertion is necessary can improve code readability and maintainability.Apply this diff to add an explanatory comment:
func (k Keeper) StageNewClobPairSideEffects(ctx sdk.Context, clobPair types.ClobPair) error { + // Ensure that this function is only called during transaction delivery. lib.AssertDeliverTxMode(ctx)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
protocol/x/clob/types/finalize_block.pb.gois excluded by!**/*.pb.go
📒 Files selected for processing (6)
- proto/dydxprotocol/clob/finalize_block.proto (1 hunks)
- protocol/x/clob/abci.go (1 hunks)
- protocol/x/clob/keeper/clob_pair.go (3 hunks)
- protocol/x/clob/keeper/keeper.go (4 hunks)
- protocol/x/listing/keeper/listing.go (1 hunks)
- protocol/x/listing/types/expected_keepers.go (1 hunks)
🧰 Additional context used
🪛 buf
proto/dydxprotocol/clob/finalize_block.proto
7-7: syntax error: unexpected int literal
(COMPILE)
🔇 Additional comments (7)
proto/dydxprotocol/clob/finalize_block.proto (2)
1-7: LGTM: File structure and imports are well-defined.The file structure follows Protocol Buffers best practices:
- Proto3 syntax is used.
- Package is clearly defined.
- Necessary import for
clob_pair.protois included.- The
go_packageoption is correctly specified for Go code generation.This structure promotes good organization and modularity in the project.
🧰 Tools
🪛 buf
7-7: syntax error: unexpected int literal
(COMPILE)
8-8:⚠️ Potential issueRemove unexpected character on line 8.
There's an unexpected "3" on line 8 which doesn't belong in the proto file. This is causing a syntax error detected by the static analysis tool.
Please remove this character:
-3This will resolve the syntax error and ensure the proto file is correctly formatted.
Likely invalid or redundant comment.
protocol/x/listing/types/expected_keepers.go (1)
38-38: Approve the interface change and verify related updates.The change from
CreateClobPairStructurestoStageNewClobPairSideEffectsaligns with the PR objectives and suggests a more staged approach to CLOB pair creation. This is a good improvement in terms of separation of concerns.To ensure this change is consistently applied throughout the codebase:
Please ensure that:
- The
StageNewClobPairSideEffectsmethod is properly implemented in the concreteClobKeeperstruct.- All calls to the former
CreateClobPairStructuresmethod are updated to useStageNewClobPairSideEffects.- Any relevant tests are updated to reflect this change in functionality.
✅ Verification successful
Change successfully applied and verified.
All references to
CreateClobPairStructureshave been removed and replaced withStageNewClobPairSideEffects. The new method is properly implemented and utilized throughout the codebase, with no remaining references or issues found in test files.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage of the new method and check for any remaining references to the old method. # Test 1: Search for implementations and calls of the new method echo "Searching for StageNewClobPairSideEffects implementations and calls:" rg --type go "StageNewClobPairSideEffects" # Test 2: Search for any remaining references to the old method echo "Searching for any remaining CreateClobPairStructures references:" rg --type go "CreateClobPairStructures" # Test 3: Look for potential missed updates in test files echo "Searching for potential missed updates in test files:" rg --type go "CreateClobPairStructures" -g "*_test.go"Length of output: 1039
protocol/x/clob/abci.go (1)
54-55: LGTM. Verify implications of processing staged events.The addition of
keeper.ProcessStagedFinalizeBlockEvents(ctx)in the Precommit phase is a logical enhancement to ensure staged events are finalized before proceeding to the next block. This change aligns with the PR objective of handling CLOB pair creation side effects.Consider the following:
- Verify that this change doesn't significantly impact the performance of the Precommit phase.
- Ensure that the
ProcessStagedFinalizeBlockEventsmethod handles errors internally or consider adding error handling here if necessary.- Update relevant documentation to reflect this change in the ABCI lifecycle.
To verify the impact and usage of this new method, you can run:
protocol/x/clob/keeper/clob_pair.go (3)
72-76: LGTM: Correctly staging side effects in DeliverTx modeThe addition of code to stage side effects when in
DeliverTxmode ensures that side effects are only applied upon transaction commitment, aligning with best practices for transactional integrity.
87-106: Event addition for perpetual market creation looks goodThe addition of the indexer event for perpetual market creation is correctly implemented, with all parameters appropriately passed to
NewPerpetualMarketCreateEvent. This ensures that the indexer is notified of new market creations.
Line range hint
252-271: Removal of unusedctxparameter is appropriateThe
ctx sdk.Contextparameter has been removed fromSetClobPairIdForPerpetualas it was unused. Simplifying the function signature enhances code clarity.
protocol/x/listing/keeper/listing.go
Outdated
| k.ClobKeeper.CreatePerpetualClobPair( | ||
| ctx, | ||
| clobPairId, | ||
| perpetualId, | ||
| satypes.BaseQuantums(types.DefaultStepBaseQuantums), | ||
| types.DefaultQuantumConversionExponent, | ||
| types.SubticksPerTick_LongTail, | ||
| clobtypes.ClobPair_STATUS_ACTIVE, | ||
| ) |
There was a problem hiding this comment.
Handle possible error from CreatePerpetualClobPair
The call to k.ClobKeeper.CreatePerpetualClobPair(...) does not capture or handle any potential errors that this function might return. If CreatePerpetualClobPair can return an error, it's important to check and handle it to ensure robustness and prevent unexpected behavior.
Apply this diff to handle the potential error:
+ err = k.ClobKeeper.CreatePerpetualClobPair(
+ ctx,
+ clobPairId,
+ perpetualId,
+ satypes.BaseQuantums(types.DefaultStepBaseQuantums),
+ types.DefaultQuantumConversionExponent,
+ types.SubticksPerTick_LongTail,
+ clobtypes.ClobPair_STATUS_ACTIVE,
+ )
+ if err != nil {
+ return 0, err
+ }
- k.ClobKeeper.CreatePerpetualClobPair(
- ctx,
- clobPairId,
- perpetualId,
- satypes.BaseQuantums(types.DefaultStepBaseQuantums),
- types.DefaultQuantumConversionExponent,
- types.SubticksPerTick_LongTail,
- clobtypes.ClobPair_STATUS_ACTIVE,
- )📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| k.ClobKeeper.CreatePerpetualClobPair( | |
| ctx, | |
| clobPairId, | |
| perpetualId, | |
| satypes.BaseQuantums(types.DefaultStepBaseQuantums), | |
| types.DefaultQuantumConversionExponent, | |
| types.SubticksPerTick_LongTail, | |
| clobtypes.ClobPair_STATUS_ACTIVE, | |
| ) | |
| err = k.ClobKeeper.CreatePerpetualClobPair( | |
| ctx, | |
| clobPairId, | |
| perpetualId, | |
| satypes.BaseQuantums(types.DefaultStepBaseQuantums), | |
| types.DefaultQuantumConversionExponent, | |
| types.SubticksPerTick_LongTail, | |
| clobtypes.ClobPair_STATUS_ACTIVE, | |
| ) | |
| if err != nil { | |
| return 0, err | |
| } |
protocol/x/clob/keeper/keeper.go
Outdated
|
|
||
| switch event := stagedEvent.Event.(type) { | ||
| case *types.ClobStagedFinalizeBlockEvent_CreateClobPair: | ||
| k.ApplySideEffectsForCNewlobPair(ctx, *event.CreateClobPair) |
There was a problem hiding this comment.
Correct the function name 'ApplySideEffectsForCNewlobPair'
The function name ApplySideEffectsForCNewlobPair appears to have a typo. It should likely be ApplySideEffectsForNewClobPair or ApplySideEffectsForCreateClobPair.
Please correct the function name to the intended ApplySideEffectsForCreateClobPair to ensure the method is called correctly.
case *types.ClobStagedFinalizeBlockEvent_CreateClobPair:
- k.ApplySideEffectsForCNewlobPair(ctx, *event.CreateClobPair)
+ k.ApplySideEffectsForCreateClobPair(ctx, *event.CreateClobPair)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| k.ApplySideEffectsForCNewlobPair(ctx, *event.CreateClobPair) | |
| k.ApplySideEffectsForCreateClobPair(ctx, *event.CreateClobPair) |
protocol/x/clob/keeper/keeper.go
Outdated
| streamingManager streamingtypes.FullNodeStreamingManager | ||
| indexerEventManager indexer_manager.IndexerEventManager | ||
| streamingManager streamingtypes.FullNodeStreamingManager | ||
| finalizeBlockEventStager finalizeblock.EventStager[*types.ClobStagedFinalizeBlockEvent] |
There was a problem hiding this comment.
Initialize 'finalizeBlockEventStager' in the 'NewKeeper' function
The field finalizeBlockEventStager added to the Keeper struct is not initialized in the NewKeeper constructor. This could lead to a nil pointer dereference when ProcessStagedFinalizeBlockEvents is called.
To fix this, initialize finalizeBlockEventStager in the NewKeeper function, similar to other fields. For example:
// In the NewKeeper function initialization
keeper := &Keeper{
// ... existing fields ...
+ finalizeBlockEventStager: finalizeblock.NewEventStager[*types.ClobStagedFinalizeBlockEvent](),
}Committable suggestion was skipped due to low confidence.
protocol/x/clob/keeper/clob_pair.go
Outdated
| func (k Keeper) ApplySideEffectsForCNewlobPair( | ||
| ctx sdk.Context, | ||
| clobPair types.ClobPair, | ||
| ) { |
There was a problem hiding this comment.
Typo in function name ApplySideEffectsForCNewlobPair
The function name ApplySideEffectsForCNewlobPair appears to have a typo. It should likely be ApplySideEffectsForNewClobPair.
Apply this diff to correct the function name:
-func (k Keeper) ApplySideEffectsForCNewlobPair(
+func (k Keeper) ApplySideEffectsForNewClobPair(
ctx sdk.Context,
clobPair types.ClobPair,
) {📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| func (k Keeper) ApplySideEffectsForCNewlobPair( | |
| ctx sdk.Context, | |
| clobPair types.ClobPair, | |
| ) { | |
| func (k Keeper) ApplySideEffectsForNewClobPair( | |
| ctx sdk.Context, | |
| clobPair types.ClobPair, | |
| ) { |
protocol/x/clob/keeper/clob_pair.go
Outdated
| perpetualId, err := clobPair.GetPerpetualId() | ||
| if err != nil { | ||
| return clobPair, err | ||
| panic(err) | ||
| } |
There was a problem hiding this comment.
Avoid panicking; handle errors gracefully
Panicking on error from clobPair.GetPerpetualId() can cause the application to crash unexpectedly. It's recommended to handle the error gracefully and return an appropriate error to the caller.
Apply this diff to handle the error:
if err != nil {
- panic(err)
+ return clobPair, err
}Committable suggestion was skipped due to low confidence.
teddyding
force-pushed
the
td/pml-stager
branch
from
3b92b79
to
af18d0c
Compare
Changelist
[Describe or list the changes made in this PR]
Test Plan
[Describe how this PR was tested (if applicable)]
Author/Reviewer Checklist
state-breakinglabel.indexer-postgres-breakinglabel.PrepareProposalorProcessProposal, manually add the labelproposal-breaking.feature:[feature-name].backport/[branch-name].refactor,chore,bug.Summary by CodeRabbit
New Features
EventStagertype for improved event management during the FinalizeBlock process.ClobStagedFinalizeBlockEventto handle CLOB events during block finalization.Bug Fixes
SendFinalizedSubaccountUpdatesmethod across multiple components, streamlining the update process.Refactor
FullNodeStreamingManagerImplto utilize the newfinalizeBlockStagerfor event staging, improving clarity and maintainability.CreateClobPairfunction by integrating it withCreatePerpetualClobPair, reducing complexity.Documentation