-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add missing fields to perpetual markets kafka update #2539
Conversation
Signed-off-by: Shrenuj Bansal <[email protected]>
Caution Review failedThe pull request is closed. WalkthroughThe changes in this pull request involve updates to the Changes
Possibly related PRs
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 (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
indexer/packages/postgres/src/types/websocket-message-types.ts (1)
226-229
: Add JSDoc comments for the new derived fields.While the fields follow the interface's conventions, they would benefit from documentation explaining:
- The purpose and meaning of each field
- The expected string format (decimal places, valid ranges)
- How these values are derived
Add JSDoc comments like this:
// Derived fields + /** + * The minimum price increment for the market. + * @example "0.1" for a market that trades in $0.10 increments + */ tickSize?: string, + /** + * The minimum size increment for orders in the market. + * @example "0.001" for a market that trades in 0.001 unit increments + */ stepSize?: string,
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (2)
- indexer/packages/postgres/src/types/websocket-message-types.ts (1 hunks)
- indexer/services/ender/src/helpers/kafka-helper.ts (3 hunks)
🔇 Additional comments (5)
indexer/packages/postgres/src/types/websocket-message-types.ts (1)
226-229
: Changes look good!The new optional fields maintain backward compatibility and follow the established patterns in the interface. The string type is appropriate for financial values to avoid floating-point precision issues.
indexer/services/ender/src/helpers/kafka-helper.ts (4)
23-23
: LGTM: Import changes are appropriate.The addition of
protocolTranslations
is well-organized and necessary for the new functionality.
331-331
: LGTM: Market type field addition.The
marketType
field addition provides important market classification information.
341-342
: LGTM: Protocol translation usage for market parameters.The use of protocol translation helpers for
tickSize
andstepSize
ensures consistent calculations across the system.
Line range hint
331-348
: Verify Kafka message consumers are prepared for new fields.The addition of new fields to the perpetual market message structure may impact downstream consumers. Let's verify that all consumers are prepared to handle these new fields.
✅ Verification successful
Let's examine the message structure and its consumers more deeply.
Let's check one more aspect to see how these fields are being consumed in the websocket service.
Based on the gathered information, I can now provide a final response:
The new fields are safe to add and won't break existing consumers.
The investigation reveals:
- The
TradingPerpetualMarketMessage
interface inwebsocket-message-types.ts
defines all fields as optional (with?
modifier)- The message is primarily consumed by websocket services and handlers that use JSON serialization/deserialization
- The message structure follows a flexible schema where additional fields won't break existing consumers due to:
- Optional field definitions
- JSON's inherent forward compatibility
- Consumers only accessing documented fields they need
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find all files that might be consuming the perpetual market message # Search for files importing or using TradingPerpetualMarketMessage echo "Files potentially consuming TradingPerpetualMarketMessage:" rg -l "TradingPerpetualMarketMessage" # Search for files consuming the Kafka message echo "\nFiles potentially consuming the Kafka message:" rg -l "generatePerpetualMarketMessage"Length of output: 854
Script:
#!/bin/bash # Check the message type definition and its consumers echo "=== Checking message type definition ===" rg -A 10 "interface TradingPerpetualMarketMessage" indexer/packages/postgres/src/types/websocket-message-types.ts echo -e "\n=== Checking websocket documentation ===" rg -A 10 "TradingPerpetualMarketMessage" indexer/services/comlink/public/websocket-documentation.md echo -e "\n=== Checking handler implementations ===" rg -B 5 -A 10 "generatePerpetualMarketMessage" indexer/services/ender/src/handlers/perpetual-market-handler.ts indexer/services/ender/src/handlers/liquidity-tier-handler.tsLength of output: 6932
Script:
#!/bin/bash # Check how the websocket service handles these messages echo "=== Checking websocket message handling ===" rg -B 5 -A 10 "TradingPerpetualMarketMessage" indexer/services/comlink/src/ --type ts # Check for any tests that might verify the message structure echo -e "\n=== Checking related tests ===" rg -B 5 -A 10 "TradingPerpetualMarketMessage" indexer/services/comlink/__tests__/ --type tsLength of output: 351
priceChange24H: perpetualMarket.priceChange24H, | ||
volume24H: perpetualMarket.volume24H, | ||
trades24H: perpetualMarket.trades24H, | ||
nextFundingRate: perpetualMarket.nextFundingRate, | ||
openInterest: perpetualMarket.openInterest, | ||
baseOpenInterest: perpetualMarket.baseOpenInterest, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add null checks and type safety for numeric fields.
The new market metrics fields are directly accessed without null checks. Consider adding safety checks to handle potential undefined values.
Apply this diff to add null checks and type safety:
- priceChange24H: perpetualMarket.priceChange24H,
- volume24H: perpetualMarket.volume24H,
- trades24H: perpetualMarket.trades24H,
- nextFundingRate: perpetualMarket.nextFundingRate,
- openInterest: perpetualMarket.openInterest,
- baseOpenInterest: perpetualMarket.baseOpenInterest,
+ priceChange24H: perpetualMarket.priceChange24H ?? '0',
+ volume24H: perpetualMarket.volume24H ?? '0',
+ trades24H: perpetualMarket.trades24H ?? 0,
+ nextFundingRate: perpetualMarket.nextFundingRate ?? '0',
+ openInterest: perpetualMarket.openInterest ?? '0',
+ baseOpenInterest: perpetualMarket.baseOpenInterest ?? '0',
This ensures that:
- Numeric string fields default to '0' if undefined
- Integer fields default to 0 if undefined
- Prevents potential null/undefined errors in downstream processing
📝 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.
priceChange24H: perpetualMarket.priceChange24H, | |
volume24H: perpetualMarket.volume24H, | |
trades24H: perpetualMarket.trades24H, | |
nextFundingRate: perpetualMarket.nextFundingRate, | |
openInterest: perpetualMarket.openInterest, | |
baseOpenInterest: perpetualMarket.baseOpenInterest, | |
priceChange24H: perpetualMarket.priceChange24H ?? '0', | |
volume24H: perpetualMarket.volume24H ?? '0', | |
trades24H: perpetualMarket.trades24H ?? 0, | |
nextFundingRate: perpetualMarket.nextFundingRate ?? '0', | |
openInterest: perpetualMarket.openInterest ?? '0', | |
baseOpenInterest: perpetualMarket.baseOpenInterest ?? '0', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -3,6 +3,7 @@ name: Indexer Build & Push Images to AWS ECR for Dev / Staging branches | |||
on: # yamllint disable-line rule:truthy | |||
push: | |||
branches: | |||
- 'sbansal*' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove personal branch pattern from shared workflow.
Adding a personal branch pattern ('sbansal*'
) to the shared workflow file raises several concerns:
- Security: This allows any branch starting with "sbansal" to trigger builds and pushes to AWS ECR across multiple environments
- Resource usage: Automatic builds for personal branches could lead to unnecessary AWS resource consumption and costs
- Maintainability: Workflow triggers should remain standardized without developer-specific patterns
Recommendations:
- Remove the personal branch pattern
- Use PR-based workflows for testing instead
- If needed, create a separate workflow file for development/testing purposes
name: Indexer Build & Push Images to AWS ECR for Dev / Staging branches
on: # yamllint disable-line rule:truthy
push:
branches:
- - 'sbansal*'
- main
- 'release/indexer/v[0-9]+.[0-9]+.x' # e.g. release/indexer/v0.1.x
- 'release/indexer/v[0-9]+.x' # e.g. release/indexer/v1.x
📝 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.
- 'sbansal*' | |
- main | |
- 'release/indexer/v[0-9]+.[0-9]+.x' # e.g. release/indexer/v0.1.x | |
- 'release/indexer/v[0-9]+.x' # e.g. release/indexer/v1.x |
Signed-off-by: Shrenuj Bansal <[email protected]>
Co-authored-by: vincentwschau <[email protected]>
@Mergifyio release/indexer/v7.x |
❌ Sorry but I didn't understand the command. Please consult the commands documentation 📚. |
@Mergifyio backport release/indexer/v7.x |
✅ Backports have been created
|
Signed-off-by: Shrenuj Bansal <[email protected]> (cherry picked from commit 15aa042)
…#2542) Co-authored-by: shrenujb <[email protected]>
Changelist
Add additional fields to the perpetual markets updates needed by the websocket message to the FE
Test Plan
Existing tests
Author/Reviewer Checklist
state-breaking
label.indexer-postgres-breaking
label.PrepareProposal
orProcessProposal
, manually add the labelproposal-breaking
.feature:[feature-name]
.backport/[branch-name]
.refactor
,chore
,bug
.Summary by CodeRabbit
marketType
,tickSize
,stepSize
,priceChange24H
,volume24H
,trades24H
,nextFundingRate
,openInterest
, andbaseOpenInterest
.tickSize
andstepSize
to theTradingPerpetualMarketMessage
interface for more detailed market information.