[ENG-1296] set cap on expired orders processed per block#3243
Open
anmolagrawal345 wants to merge 8 commits intomainfrom
Open
[ENG-1296] set cap on expired orders processed per block#3243anmolagrawal345 wants to merge 8 commits intomainfrom
anmolagrawal345 wants to merge 8 commits intomainfrom
Conversation
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
Contributor
WalkthroughThis PR implements a per-block cap mechanism for removing expired stateful orders in the CLOB module. It introduces a Changes
Sequence Diagram(s)sequenceDiagram
auctor ->> EndBlocker: Trigger
EndBlocker ->> RemoveExpiredStatefulOrders: Remove expired orders
Note over RemoveExpiredStatefulOrders: Check MaxStatefulOrderRemovalsPerBlock cap
alt Cap enabled and reached
RemoveExpiredStatefulOrders -->> RemoveExpiredStatefulOrders: Break early, return partial batch
RemoveExpiredStatefulOrders ->> EndBlocker: Return expired IDs (up to cap)
else Cap disabled or not reached
RemoveExpiredStatefulOrders ->> RemoveExpiredStatefulOrders: Continue processing all
RemoveExpiredStatefulOrders ->> EndBlocker: Return all expired IDs
end
EndBlocker ->> Telemetry: Record gauge (expired order count)
EndBlocker ->> EndBlocker: Emit event
sequenceDiagram
Client ->> CLI: query clob block-limits-config
CLI ->> QueryClient: BlockLimitsConfiguration(request)
QueryClient ->> gRPC: Call BlockLimitsConfiguration
gRPC ->> ClobKeeper: BlockLimitsConfiguration(ctx, req)
ClobKeeper ->> StateStore: GetBlockLimitsConfig
StateStore -->> ClobKeeper: BlockLimitsConfig
ClobKeeper -->> gRPC: QueryBlockLimitsConfigurationResponse
gRPC -->> QueryClient: Response
QueryClient -->> CLI: Response
CLI -->> Client: Display config
sequenceDiagram
Governance ->> MsgServer: UpdateBlockLimitsConfig(authority, config)
MsgServer ->> Authority: Verify HasAuthority
alt Authority valid
Authority -->> MsgServer: OK
MsgServer ->> ClobKeeper: UpdateBlockLimitsConfig(ctx, config)
ClobKeeper ->> StateStore: setBlockLimitsConfig
StateStore -->> ClobKeeper: Stored
ClobKeeper -->> MsgServer: Success
MsgServer -->> Governance: MsgUpdateBlockLimitsConfigResponse
else Authority invalid
Authority -->> MsgServer: ErrInvalidSigner
MsgServer -->> Governance: Error
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–30 minutes Areas requiring extra attention:
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (42)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
.github/workflows/protocol-build-and-push.yml(1 hunks)protocol/x/clob/abci.go(1 hunks)protocol/x/clob/flags/flags.go(6 hunks)protocol/x/clob/flags/flags_test.go(5 hunks)protocol/x/clob/keeper/stateful_order_state.go(2 hunks)protocol/x/clob/keeper/stateful_order_state_test.go(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: hwray
Repo: dydxprotocol/v4-chain PR: 2597
File: indexer/services/ender/src/scripts/handlers/dydx_update_perpetual_v1_handler.sql:16-20
Timestamp: 2024-11-22T18:12:04.606Z
Learning: Avoid suggesting changes to deprecated functions such as `dydx_update_perpetual_v1_handler` in `indexer/services/ender/src/scripts/handlers/dydx_update_perpetual_v1_handler.sql` if they are unchanged in the PR.
Learnt from: anmolagrawal345
Repo: dydxprotocol/v4-chain PR: 2780
File: protocol/x/clob/keeper/twap_order_state.go:137-138
Timestamp: 2025-04-15T16:57:26.546Z
Learning: TWAP order cancellations and expiries will be handled in a dedicated follow-up PR, separate from the initial implementation of TWAP order functionality in the end blocker.
📚 Learning: 2025-04-15T16:58:46.335Z
Learnt from: anmolagrawal345
Repo: dydxprotocol/v4-chain PR: 2780
File: protocol/x/clob/keeper/twap_order_state_test.go:191-209
Timestamp: 2025-04-15T16:58:46.335Z
Learning: For TWAP orders, message validation in message_place_order.go handles edge cases with comprehensive checks for parameters like durations and intervals, making it unnecessary to test invalid parameters in twap_order_state_test.go which only receives pre-validated inputs.
Applied to files:
protocol/x/clob/keeper/stateful_order_state_test.goprotocol/x/clob/flags/flags_test.go
🧬 Code graph analysis (4)
protocol/x/clob/abci.go (4)
protocol/lib/metrics/lib.go (1)
SetGauge(38-40)protocol/x/clob/types/keys.go (1)
ModuleName(6-6)protocol/lib/metrics/metric_keys.go (1)
EndBlocker(91-91)protocol/lib/metrics/constants.go (1)
Count(9-9)
protocol/x/clob/keeper/stateful_order_state.go (2)
protocol/app/flags/flags.go (1)
Flags(13-36)protocol/x/clob/flags/flags.go (1)
MaxStatefulOrderRemovalsPerBlock(30-30)
protocol/x/clob/keeper/stateful_order_state_test.go (4)
protocol/testutil/constants/stateful_orders.go (5)
ConditionalOrder_Alice_Num0_Id0_Clob0_Buy5_Price10_GTBT15_StopLoss20(457-470)ConditionalOrder_Alice_Num1_Id0_Clob0_Sell5_Price10_GTB15(932-943)LongTermOrder_Alice_Num0_Id0_Clob0_Buy5_Price10_GTBT20(131-142)ConditionalOrder_Alice_Num1_Id1_Clob0_Sell50_Price5_GTB30(944-955)LongTermOrder_Alice_Num1_Id1_Clob0_Sell25_Price30_GTBT10(191-202)protocol/x/clob/memclob/memclob.go (1)
NewMemClobPriceTimePriority(57-66)protocol/testutil/keeper/clob.go (1)
NewClobKeepersTestContext(61-73)protocol/x/clob/flags/flags.go (1)
MaxStatefulOrderRemovalsPerBlock(30-30)
protocol/x/clob/flags/flags_test.go (1)
protocol/x/clob/flags/flags.go (2)
MaxStatefulOrderRemovalsPerBlock(30-30)DefaultMaxStatefulOrderRemovalsPerBlock(44-44)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (32)
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-vulcan / (vulcan) Build and Push
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-auxo-lambda / (auxo) Build and Push Lambda
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-ecs-service-ender / (ender) Build and Push
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-bazooka-lambda / (bazooka) Build and Push Lambda
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-vulcan / (vulcan) Build and Push
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-bazooka-lambda / (bazooka) Build and Push Lambda
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-ecs-service-roundtable / (roundtable) Build and Push
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-ecs-service-socks / (socks) Build and Push
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-ecs-service-socks / (socks) Build and Push
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-ecs-service-comlink / (comlink) Build and Push
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-ecs-service-ender / (ender) Build and Push
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-auxo-lambda / (auxo) Build and Push Lambda
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-ecs-service-comlink / (comlink) Build and Push
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-ecs-service-roundtable / (roundtable) Build and Push
- GitHub Check: golangci-lint
- GitHub Check: benchmark
- GitHub Check: test-coverage-upload
- GitHub Check: build
- GitHub Check: liveness-test
- GitHub Check: test-race
- GitHub Check: unit-end-to-end-and-integration
- GitHub Check: check-sample-pregenesis-up-to-date
- GitHub Check: container-tests
- GitHub Check: build-and-push-testnet
- GitHub Check: build-and-push-mainnet
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: Analyze (go)
- GitHub Check: Summary
- GitHub Check: build-and-push-dev2
- GitHub Check: build-and-push-dev4
- GitHub Check: build-and-push-staging
- GitHub Check: build-and-push-dev
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
Contributor
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
proto/dydxprotocol/clob/block_limits_config.proto (1)
6-12: Consider enhancing documentation with value guidance.While the documentation clearly explains the purpose, it would be helpful to document:
- What the default/recommended value is
- What constitutes a reasonable range (e.g., minimum value > 0)
- Impact of setting this value too low (order backlog) vs. too high (reduced protection)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📥 Commits
Reviewing files that changed from the base of the PR and between 81f5054aae5768d51e3719725abda55bf6e2550c and 8341eb0.
⛔ Files ignored due to path filters (1)
protocol/x/clob/types/block_limits_config.pb.gois excluded by!**/*.pb.go
📒 Files selected for processing (3)
proto/dydxprotocol/clob/block_limits_config.proto(1 hunks)proto/dydxprotocol/clob/tx.proto(3 hunks)protocol/x/clob/module_test.go(2 hunks)
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: hwray
Repo: dydxprotocol/v4-chain PR: 2597
File: indexer/services/ender/src/scripts/handlers/dydx_update_perpetual_v1_handler.sql:16-20
Timestamp: 2024-11-22T18:12:04.606Z
Learning: Avoid suggesting changes to deprecated functions such as `dydx_update_perpetual_v1_handler` in `indexer/services/ender/src/scripts/handlers/dydx_update_perpetual_v1_handler.sql` if they are unchanged in the PR.
Learnt from: anmolagrawal345
Repo: dydxprotocol/v4-chain PR: 2780
File: protocol/x/clob/keeper/twap_order_state.go:137-138
Timestamp: 2025-04-15T16:57:26.546Z
Learning: TWAP order cancellations and expiries will be handled in a dedicated follow-up PR, separate from the initial implementation of TWAP order functionality in the end blocker.
📚 Learning: 2025-05-24T00:45:00.519Z
Learnt from: anmolagrawal345
Repo: dydxprotocol/v4-chain PR: 2837
File: proto/dydxprotocol/clob/order.proto:4-4
Timestamp: 2025-05-24T00:45:00.519Z
Learning: In the dydxprotocol/v4-chain repository, cosmos_proto dependencies are managed through buf.yaml configuration rather than being physically present in the repository. The import "cosmos_proto/cosmos.proto" is a standard pattern used across 28+ proto files for cosmos address annotations like (cosmos_proto.scalar) = "cosmos.AddressString".
Applied to files:
proto/dydxprotocol/clob/block_limits_config.protoproto/dydxprotocol/clob/tx.proto
📚 Learning: 2024-11-15T16:17:29.092Z
Learnt from: hwray
Repo: dydxprotocol/v4-chain PR: 2551
File: protocol/x/clob/types/expected_keepers.go:86-90
Timestamp: 2024-11-15T16:17:29.092Z
Learning: The function `GetCrossInsuranceFundBalance` in `protocol/x/clob/types/expected_keepers.go` already existed and was just moved in this PR; changes to its error handling may be out of scope.
Applied to files:
protocol/x/clob/module_test.go
📚 Learning: 2025-10-06T20:00:48.549Z
Learnt from: anmolagrawal345
Repo: dydxprotocol/v4-chain PR: 3079
File: protocol/x/clob/types/leverage.go:10-56
Timestamp: 2025-10-06T20:00:48.549Z
Learning: In the leverage update flow for protocol/x/clob, the `ValidateUpdateLeverageMsg` function performs basic validation (non-nil checks, non-zero leverage, unique IDs, valid clob pair existence), while maximum leverage validation against `GetMaxLeverageForPerpetual` is intentionally deferred to the `UpdateLeverage` keeper method.
Applied to files:
proto/dydxprotocol/clob/tx.proto
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (42)
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-auxo-lambda / (auxo) Build and Push Lambda
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-ecs-service-comlink / (comlink) Build and Push
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-bazooka-lambda / (bazooka) Build and Push Lambda
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-vulcan / (vulcan) Build and Push
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-ecs-service-roundtable / (roundtable) Build and Push
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-ecs-service-socks / (socks) Build and Push
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-ecs-service-ender / (ender) Build and Push
- GitHub Check: check-sample-pregenesis-up-to-date
- GitHub Check: call-build-ecs-service-roundtable / (roundtable) Check docker image build
- GitHub Check: call-build-ecs-service-vulcan / (vulcan) Check docker image build
- GitHub Check: call-build-ecs-service-socks / (socks) Check docker image build
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-ecs-service-roundtable / (roundtable) Build and Push
- GitHub Check: build-and-push-testnet
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-bazooka-lambda / (bazooka) Build and Push Lambda
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-vulcan / (vulcan) Build and Push
- GitHub Check: call-build-ecs-service-ender / (ender) Check docker image build
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-ecs-service-socks / (socks) Build and Push
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-auxo-lambda / (auxo) Build and Push Lambda
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-ecs-service-ender / (ender) Build and Push
- GitHub Check: call-build-ecs-service-comlink / (comlink) Check docker image build
- GitHub Check: check-build-auxo
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-ecs-service-comlink / (comlink) Build and Push
- GitHub Check: check-build-bazooka
- GitHub Check: unit-end-to-end-and-integration
- GitHub Check: liveness-test
- GitHub Check: test / run_command
- GitHub Check: test-coverage-upload
- GitHub Check: test-race
- GitHub Check: container-tests
- GitHub Check: lint
- GitHub Check: build-and-push-mainnet
- GitHub Check: run_command
- GitHub Check: build
- GitHub Check: benchmark
- GitHub Check: golangci-lint
- GitHub Check: Analyze (go)
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: build-and-push-staging
- GitHub Check: build-and-push-dev4
- GitHub Check: build-and-push-dev
- GitHub Check: build-and-push-dev2
- GitHub Check: Summary
🔇 Additional comments (4)
protocol/x/clob/module_test.go (2)
153-153: LGTM! Interface registration count correctly updated.The increase from 20 to 22 registered interfaces is consistent with the addition of
MsgUpdateBlockLimitsConfigandMsgUpdateBlockLimitsConfigResponse.
258-267: LGTM! Query command test correctly updated.The test properly reflects the addition of the new
get-block-limits-configcommand and correctly shifts all existing command indices by 1.proto/dydxprotocol/clob/tx.proto (1)
14-14: LGTM! BlockLimitsConfig transaction messages follow established patterns.The new import, RPC definition, and message types are consistent with existing configuration update mechanisms in the codebase (e.g.,
MsgUpdateLiquidationsConfig,MsgUpdateBlockRateLimitConfiguration). The authority-based governance pattern and field annotations are correctly applied.Also applies to: 51-53, 222-237
proto/dydxprotocol/clob/block_limits_config.proto (1)
11-11: The review comment is based on a misunderstanding. The code explicitly documents that a value of 0 is valid and means no cap (process all expired orders), and the validation function confirms 0 is a valid value meaning "no cap". This is an intentional design choice, not a security vulnerability.Likely an incorrect or invalid review comment.
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
mainnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
anmolagrawal345
temporarily deployed
to
testnet
GitHub Actions
Inactive
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
protocol/app/msgs/all_msgs.go(1 hunks)protocol/app/msgs/normal_msgs.go(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: anmolagrawal345
Repo: dydxprotocol/v4-chain PR: 2780
File: protocol/x/clob/keeper/twap_order_state.go:137-138
Timestamp: 2025-04-15T16:57:26.546Z
Learning: TWAP order cancellations and expiries will be handled in a dedicated follow-up PR, separate from the initial implementation of TWAP order functionality in the end blocker.
Learnt from: hwray
Repo: dydxprotocol/v4-chain PR: 2597
File: indexer/services/ender/src/scripts/handlers/dydx_update_perpetual_v1_handler.sql:16-20
Timestamp: 2024-11-22T18:12:04.606Z
Learning: Avoid suggesting changes to deprecated functions such as `dydx_update_perpetual_v1_handler` in `indexer/services/ender/src/scripts/handlers/dydx_update_perpetual_v1_handler.sql` if they are unchanged in the PR.
📚 Learning: 2025-10-06T20:00:48.549Z
Learnt from: anmolagrawal345
Repo: dydxprotocol/v4-chain PR: 3079
File: protocol/x/clob/types/leverage.go:10-56
Timestamp: 2025-10-06T20:00:48.549Z
Learning: In the leverage update flow for protocol/x/clob, the `ValidateUpdateLeverageMsg` function performs basic validation (non-nil checks, non-zero leverage, unique IDs, valid clob pair existence), while maximum leverage validation against `GetMaxLeverageForPerpetual` is intentionally deferred to the `UpdateLeverage` keeper method.
Applied to files:
protocol/app/msgs/normal_msgs.goprotocol/app/msgs/all_msgs.go
🧬 Code graph analysis (1)
protocol/app/msgs/normal_msgs.go (2)
indexer/packages/v4-protos/src/codegen/dydxprotocol/clob/tx.ts (2)
MsgUpdateBlockLimitsConfig(391-400)MsgUpdateBlockLimitsConfig(1438-1484)protocol/x/clob/types/tx.pb.go (3)
MsgUpdateBlockLimitsConfig(1096-1102)MsgUpdateBlockLimitsConfig(1106-1106)MsgUpdateBlockLimitsConfig(1107-1109)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (43)
- GitHub Check: golangci-lint
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-auxo-lambda / (auxo) Build and Push Lambda
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-bazooka-lambda / (bazooka) Build and Push Lambda
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-vulcan / (vulcan) Build and Push
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-ecs-service-socks / (socks) Build and Push
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-ecs-service-ender / (ender) Build and Push
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-ecs-service-roundtable / (roundtable) Build and Push
- GitHub Check: (Public Testnet) Build and Push ECS Services / call-build-and-push-ecs-service-comlink / (comlink) Build and Push
- GitHub Check: test / run_command
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-ecs-service-roundtable / (roundtable) Build and Push
- GitHub Check: test-coverage-upload
- GitHub Check: liveness-test
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-ecs-service-socks / (socks) Build and Push
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-bazooka-lambda / (bazooka) Build and Push Lambda
- GitHub Check: unit-end-to-end-and-integration
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-vulcan / (vulcan) Build and Push
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-ecs-service-ender / (ender) Build and Push
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-auxo-lambda / (auxo) Build and Push Lambda
- GitHub Check: test-race
- GitHub Check: (Mainnet) Build and Push ECS Services / call-build-and-push-ecs-service-comlink / (comlink) Build and Push
- GitHub Check: benchmark
- GitHub Check: call-build-ecs-service-vulcan / (vulcan) Check docker image build
- GitHub Check: call-build-ecs-service-socks / (socks) Check docker image build
- GitHub Check: call-build-ecs-service-roundtable / (roundtable) Check docker image build
- GitHub Check: check-build-auxo
- GitHub Check: call-build-ecs-service-ender / (ender) Check docker image build
- GitHub Check: check-build-bazooka
- GitHub Check: call-build-ecs-service-comlink / (comlink) Check docker image build
- GitHub Check: container-tests
- GitHub Check: build
- GitHub Check: check-sample-pregenesis-up-to-date
- GitHub Check: build-and-push-testnet
- GitHub Check: protocol-gen
- GitHub Check: lint
- GitHub Check: build-and-push-mainnet
- GitHub Check: run_command
- GitHub Check: build-and-push-dev4
- GitHub Check: build-and-push-staging
- GitHub Check: build-and-push-dev
- GitHub Check: build-and-push-dev2
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: Analyze (go)
- GitHub Check: Summary
🔇 Additional comments (1)
protocol/app/msgs/all_msgs.go (1)
213-214: LGTM! Message type registration follows established pattern.The new message types are correctly added to the
AllTypeMessagesregistry, consistent with similar configuration update messages in the clob module.
Comment on lines
+237
to
+238
| "/dydxprotocol.clob.MsgUpdateBlockLimitsConfig": &clob.MsgUpdateBlockLimitsConfig{}, | ||
| "/dydxprotocol.clob.MsgUpdateBlockLimitsConfigResponse": nil, |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
Verify whether this authority-controlled message should be externally submittable.
MsgUpdateBlockLimitsConfig is being added to NormalMsgs, which allows external users to submit it. However, similar authority-controlled configuration messages in the clob module (MsgUpdateBlockRateLimitConfiguration, MsgUpdateEquityTierLimitConfiguration, MsgUpdateLiquidationsConfig) are not present in NormalMsgs, making them governance-only.
Since MsgUpdateBlockLimitsConfig has an authority field and updates system-wide block limits, it likely should follow the same pattern as other config update messages and be excluded from NormalMsgs.
Including it in NormalMsgs would allow any external user to submit this message (though it would fail authorization checks), potentially creating unnecessary gas consumption and an inconsistent message access pattern.
Run the following script to compare the message registration patterns and verify the authorization implementation:
🏁 Script executed:
#!/bin/bash
# Description: Check message registration patterns for similar config update messages and verify authorization
echo "=== Checking similar config update messages in normal_msgs.go ==="
rg -n "MsgUpdate.*Config" protocol/app/msgs/normal_msgs.go
echo -e "\n=== Checking all clob config update messages in all_msgs.go ==="
rg -n "dydxprotocol.clob.MsgUpdate.*Config" protocol/app/msgs/all_msgs.go
echo -e "\n=== Checking MsgUpdateBlockLimitsConfig message handler/server implementation ==="
fd -e go -x grep -l "MsgUpdateBlockLimitsConfig" {} \; | head -10
echo -e "\n=== Checking authorization pattern for MsgUpdateBlockLimitsConfig ==="
rg -A 5 "func.*MsgUpdateBlockLimitsConfig.*authority" --type goLength of output: 1303
🏁 Script executed:
#!/bin/bash
# Examine MsgUpdateBlockLimitsConfig handler implementation to verify authorization
echo "=== MsgUpdateBlockLimitsConfig handler implementation ==="
cat protocol/x/clob/keeper/msg_server_update_block_limits_config.go
echo -e "\n=== MsgUpdateBlockLimitsConfig message definition ==="
cat protocol/x/clob/types/message_update_block_limits_config.go
echo -e "\n=== Check if similar config messages appear in normal_msgs.go ==="
rg "MsgUpdateBlockRateLimitConfiguration|MsgUpdateEquityTierLimitConfiguration|MsgUpdateLiquidationsConfig" protocol/app/msgs/normal_msgs.goLength of output: 1697
🏁 Script executed:
#!/bin/bash
# Verify similar config messages also have authority checks
echo "=== MsgUpdateBlockRateLimitConfiguration handler ==="
cat protocol/x/clob/keeper/msg_server_update_block_rate_limit_configuration.go 2>/dev/null | head -40
echo -e "\n=== MsgUpdateEquityTierLimitConfiguration handler ==="
cat protocol/x/clob/keeper/msg_server_update_equity_tier_limit_configuration.go 2>/dev/null | head -40
echo -e "\n=== MsgUpdateLiquidationsConfig handler ==="
cat protocol/x/clob/keeper/msg_server_update_liquidations_config.go 2>/dev/null | head -40
echo -e "\n=== Confirm none of these are in normal_msgs.go ==="
grep -c "MsgUpdateBlockRateLimitConfiguration\|MsgUpdateEquityTierLimitConfiguration\|MsgUpdateLiquidationsConfig" protocol/app/msgs/normal_msgs.go || echo "Not found in normal_msgs.go (as expected)"Length of output: 1109
Remove MsgUpdateBlockLimitsConfig from NormalMsgs to align with other authority-controlled configuration messages.
The verification confirms the inconsistency raised in the review comment. MsgUpdateBlockLimitsConfig has an authority check identical to MsgUpdateLiquidationsConfig:
- Both use
k.Keeper.HasAuthority(msg.Authority) - Both return
govtypes.ErrInvalidSignerif unauthorized
However, MsgUpdateBlockLimitsConfig is in normal_msgs.go (line 237), while MsgUpdateLiquidationsConfig and other similar config messages are not. This allows external users to submit a governance-controlled message, creating unnecessary gas consumption and breaking the intended access pattern.
Remove lines 237-238 from protocol/app/msgs/normal_msgs.go and verify the message is only registered in all_msgs.go where it belongs.
🤖 Prompt for AI Agents
In protocol/app/msgs/normal_msgs.go around lines 237-238, remove the entries for
"/dydxprotocol.clob.MsgUpdateBlockLimitsConfig" and its response so the message
is no longer registered as a normal message; this message is
authority-controlled and should only be registered in all_msgs.go. Delete those
two lines, run go build/tests to ensure no missing registrations, and confirm
MsgUpdateBlockLimitsConfig remains present only in all_msgs.go (or the
authority-specific registration) so external users cannot submit it via
NormalMsgs.
jusbar23
reviewed
Nov 10, 2025
| - main | ||
| - 'release/protocol/v[0-9]+.[0-9]+.x' # e.g. release/protocol/v0.1.x | ||
| - 'release/protocol/v[0-9]+.x' # e.g. release/protocol/v1.x | ||
| - 'anmol/eng-1296' |
| 1022, | ||
| "Liquidation conflicts with ClobPair status", | ||
| ) | ||
| ErrInvalidBlockLimitsConfig = errorsmod.Register( |
Contributor
There was a problem hiding this comment.
Do we use this? Doesn't seem like we have any validation logic
Contributor
Author
There was a problem hiding this comment.
deleted - the only validation logic lives in the server itself which verifies the message came from an authorized address. otherwise, think we can just use the value. dont need to check negative values either since its a uint
| // Validate checks that the BlockLimitsConfig is valid. | ||
| // Note: MaxStatefulOrderRemovalsPerBlock can be 0, which means no cap (process all expired orders). | ||
| func (config *BlockLimitsConfig) Validate() error { | ||
| // No validation needed - 0 is a valid value meaning "no cap" |
Contributor
There was a problem hiding this comment.
Do we want to set an upper bound for his?
Contributor
Author
There was a problem hiding this comment.
dont think so since its governance protected. if for some reason we need to bump it past any threshold, we'll have to do an upgrade to support it
shrenujb
reviewed
Nov 10, 2025
|
|
||
| // MsgUpdateBlockLimitsConfig is a request type for updating the block limits | ||
| // configuration. | ||
| message MsgUpdateBlockLimitsConfig { |
Contributor
There was a problem hiding this comment.
Would this be a gov msg? Are there other limits we already have which we use gov msgs to update?
Contributor
Author
There was a problem hiding this comment.
Yep this follows the same pattern as MsgUpdateLiquidationConfig which also seems gov protected.
| // The maximum number of expired stateful orders that can be removed from | ||
| // state in a single block. This prevents performance degradation when | ||
| // processing a large number of expired orders. | ||
| uint32 max_stateful_order_removals_per_block = 1; |
Contributor
There was a problem hiding this comment.
Is there a strong reason not to put this under BlockRateLimitConfiguration, which is also stored in state?
Not too concerned about the differences between this field (end blocker) and existing block rate limits (checktx)
Doing that would save us from so many stubs/new messages added in this PR
| // The maximum number of expired stateful orders that can be removed from | ||
| // state in a single block. This prevents performance degradation when | ||
| // processing a large number of expired orders. | ||
| uint32 max_stateful_order_removals_per_block = 1; |
Contributor
There was a problem hiding this comment.
For my context, why did we decide to add this recently? Is this an AI from a security report?
| numRemoved := uint32(0) | ||
|
|
||
| // Process orders up to the cap (if set), otherwise process all | ||
| for ; it.Valid(); it.Next() { |
Contributor
There was a problem hiding this comment.
A bit cleaner to put condition in loop guard
maxRemovals := blockLimitsConfig.MaxStatefulOrderRemovalsPerBlock
numRemoved := uint32(0)
// Process orders up to the cap (if set), otherwise process all
for ; it.Valid() && (maxRemovals == 0 || numRemoved < maxRemovals); it.Next() {
var orderId types.OrderId
k.cdc.MustUnmarshal(it.Value(), &orderId)
expiredOrderIds = append(expiredOrderIds, orderId)
store.Delete(it.Key())
numRemoved++
}
return expiredOrderIds
}
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
4 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.
Changelist
This change builds off the same pattern for setting caps on deleveraging and liquidations per block. We need to cap the expired orders removal per block to prevent the situation in which the end blocker is stuck removing a large number of orders (a potential attack vector).
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
Improvements