[IC-1056] update-api-docs-for-v120-chain-upgrade#186
Merged
Conversation
…d indexer v1.19.41. Regenerated examples based on Python SDK v1.15.0-rc1 and Go SDK v1.62.0-rc1. Added a section for the MsgBatchLiquidatePositions message.
📝 WalkthroughWalkthroughThis PR comprehensively documents the Injective v1.20.0 chain upgrade. It bumps Makefile version pins, adds a new procedural guide for future chain upgrades in the README, and updates API documentation across 100+ files to reflect new features: oracle type additions (PythPro, SedaFast), error code changes, a new cross-margin trading system, RFQ gateway protocols, enhanced derivative trading APIs, and new indexer streaming capabilities. Changesv1.20.0 Chain Release Documentation
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
|
….2. Regenerated examples based on Python SDK v1.15.0 and Go SDK v1.62.0. Added a section for the MsgBatchLiquidatePositions message.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🧹 Nitpick comments (6)
source/json_tables/injective/oracle/MsgRelayBandRates.json (1)
1-32: ⚡ Quick winAdd descriptions for all parameters.
All five parameters (
relayer,symbols,rates,resolve_times,requestIDs) have empty descriptions. Adding descriptive text would improve documentation quality and help users understand the purpose of each parameter.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@source/json_tables/injective/oracle/MsgRelayBandRates.json` around lines 1 - 32, The JSON schema for MsgRelayBandRates is missing descriptions for all parameters; update the entries for "relayer", "symbols", "rates", "resolve_times", and "requestIDs" to include concise descriptions explaining their purpose (e.g., relayer: address submitting rates; symbols: list of asset symbols being reported; rates: reported price values corresponding to symbols; resolve_times: UNIX timestamps when each rate was resolved; requestIDs: band/oracle request identifiers matching each symbol/rate), so each parameter clearly documents expected value, format, and relation to the others.source/json_tables/injective/oracle/MsgRequestBandIBCRates.json (1)
1-14: ⚡ Quick winAdd descriptions for all parameters.
Both parameters (
sender,request_id) have empty descriptions. Adding descriptive text would improve documentation quality and help users understand the purpose of each parameter.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@source/json_tables/injective/oracle/MsgRequestBandIBCRates.json` around lines 1 - 14, Update the JSON parameter entries in MsgRequestBandIBCRates.json by adding clear, concise descriptions for the "sender" and "request_id" fields: for "sender" describe it as the bech32 address (or account) initiating the IBC Band rate request, and for "request_id" describe it as the unique unsigned 64-bit identifier used to correlate this request with its response and retries; ensure the "Description" values for the objects referencing "sender" and "request_id" are non-empty, accurate, and written consistently with the rest of the JSON docs.source/json_tables/injective/exchange/v2/DerivativeMarketParamUpdateProposal.json (1)
102-106: ⚡ Quick winDocument intended mapping between
cross_margin_eligible(bool) andcross_margin_eligibility(CrossMarginEligibility)
DerivativeMarketParamUpdateProposal.json’scross_margin_eligibility(CrossMarginEligibility) matchesMsgUpdateDerivativeMarket.json, andCrossMarginEligibilityis a tri-state enum (CM_ELIGIBILITY_UNSPECIFIED/CM_ELIGIBILITY_ELIGIBLE/CM_ELIGIBILITY_INELIGIBLE). Add/confirm documentation for how clients should translate the market’scross_margin_eligibleboolean into the proposal’s enum semantics to avoid integration mistakes.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@source/json_tables/injective/exchange/v2/DerivativeMarketParamUpdateProposal.json` around lines 102 - 106, Update DerivativeMarketParamUpdateProposal.json to document the intended mapping between the market boolean cross_margin_eligible and the tri-state enum CrossMarginEligibility used by cross_margin_eligibility (refer to MsgUpdateDerivativeMarket for context); specify that cross_margin_eligible == true maps to CM_ELIGIBILITY_ELIGIBLE, cross_margin_eligible == false maps to CM_ELIGIBILITY_INELIGIBLE, and absent/null should map to CM_ELIGIBILITY_UNSPECIFIED, and also note the reverse mapping rule when reading proposals back into market bools (CM_ELIGIBILITY_ELIGIBLE -> true, CM_ELIGIBILITY_INELIGIBLE -> false, CM_ELIGIBILITY_UNSPECIFIED -> treat as unset/null).source/json_tables/indexer/injective_rfq_gw_rpc/RFQGwPrepareRequestType.json (1)
3-36: ⚡ Quick winCore trading parameters are undocumented.
client_id,market_id,direction,margin,quantity,worst_price, andtaker_addressall carry emptyDescriptionvalues, while the surrounding metadata fields (expiry,quotes_wait_time_ms, etc.) are documented. These are the primary inputs an integrator must populate, so a short description (expected format, units, accepted values fordirection) would meaningfully reduce integration errors. The same gap repeats inRFQGwPrepareEip712RequestType.jsonandRFQGwPrepareEip712AutoSignRequestType.json.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@source/json_tables/indexer/injective_rfq_gw_rpc/RFQGwPrepareRequestType.json` around lines 3 - 36, Add concise Description entries for the undocumented parameters client_id, market_id, direction, margin, quantity, worst_price, and taker_address: specify expected format (e.g., UUID or string pattern) for client_id and market_id, allowed values for direction (e.g., "buy"|"sell"), numeric type and units/precision for margin, quantity and worst_price (e.g., decimal string, asset units or base/quote, and precision/scale), and the expected address format for taker_address (e.g., hex EOA). Apply the same descriptive updates to the corresponding parameter entries in RFQGwPrepareEip712RequestType.json and RFQGwPrepareEip712AutoSignRequestType.json so integrators know required formats, units and valid values.source/json_tables/indexer/injective_derivative_exchange_rpc/StreamPositionsV2Response.json (1)
12-15: 💤 Low valueConsider expanding the description with valid values.
The description "Position update type" is generic. Consider documenting the valid values or providing examples (e.g., "insert", "update", "delete" or similar enum values) to help API consumers understand what to expect.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@source/json_tables/indexer/injective_derivative_exchange_rpc/StreamPositionsV2Response.json` around lines 12 - 15, Update the "Description" for the parameter "operation_type" in StreamPositionsV2Response.json to list the allowed/expected values and examples; e.g., replace "Position update type" with a short enum-like description such as "Position update type — allowed values: 'insert', 'update', 'delete' (or other domain-specific values); describes the kind of operation applied to the position" so API consumers know the exact semantics and examples of operation_type.source/json_tables/indexer/injective_tc_derivatives_rpc/StreamPositionsResponse.json (1)
12-15: 💤 Low valueConsider expanding the description with valid values.
The description "Position update type" is generic. Consider documenting the valid values or providing examples to help API consumers understand what to expect.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@source/json_tables/indexer/injective_tc_derivatives_rpc/StreamPositionsResponse.json` around lines 12 - 15, Update the "Description" for the Parameter "operation_type" in StreamPositionsResponse.json to enumerate valid values and give examples so consumers know expected strings; reference the operation_type field and either list the allowed tokens (e.g., "insert", "update", "delete", "snapshot") or indicate that the schema uses an enum and show the possible values, and if applicable mention whether values are case-sensitive or have synonyms.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@README.md`:
- Around line 73-75: The README contains unlabeled fenced code blocks for
commands (make update-all-proto-related-files, make refresh-examples, ./slate.sh
serve) which triggers markdownlint MD040; update each triple-backtick fence
around those command examples to include a language identifier (e.g., change ```
to ```bash) for the blocks that contain those commands (the instances around the
lines referencing make update-all-proto-related-files, make refresh-examples,
and ./slate.sh serve) so the code blocks are labeled and MD040 is resolved.
In `@source/includes/_derivatives.md`:
- Line 5845: The intra-page link fragment for MsgLiquidatePosition is invalid;
locate the heading "## MsgLiquidatePosition" and update the link target from
"`#chain-exchange-for-derivatives-msgliquidateposition`" to the actual generated
anchor for that heading (e.g., the anchor generated from
"MsgLiquidatePosition"); in other words, find the current link referencing
MsgLiquidatePosition and replace its fragment with the exact anchor string
produced for the "## MsgLiquidatePosition" section so the link correctly
navigates to that heading.
In `@source/json_tables/indexer/event_provider_api/StreamABCIEventsRequest.json`:
- Around line 14-19: The "Description" for the parameter "batch_size" in
StreamABCIEventsRequest.json is truncated; confirm the exact in-sync behavior
with the author or spec, then update the Description to a complete sentence that
clearly states what happens once the stream is in sync (for example: "Once the
stream is in sync, the batch_size controls how many blocks are returned per
response, subject to the service cap"), keeping the "Parameter", "Type", and
"Required" fields unchanged; ensure the new text reads as a complete sentence
and matches the confirmed behavior.
In
`@source/json_tables/indexer/injective_rfq_rpc/CreateConditionalOrderRequest.json`:
- Around line 14-25: Update the "Required" flags in
CreateConditionalOrderRequest.json to match the descriptions: set "sign_mode"
Required to "No" (since it defaults to "v1" when omitted) and set "evm_chain_id"
Required to "No (required when sign_mode is \"v2\")" to indicate conditional
requirement; ensure the entries for the parameters "sign_mode" and
"evm_chain_id" reflect these exact text changes so consumers see optional vs
conditional requirement correctly.
In
`@source/json_tables/indexer/injective_rfq_rpc/TakerStreamStreamingRequest.json`:
- Around line 26-37: The "Required" flags are incorrect: set
"conditional_order_sign_mode" to optional ("Required": "No") because its
description states it defaults to "v1" when omitted, and change
"conditional_order_evm_chain_id" to be conditionally required (e.g., "Required":
"Yes when conditional_order_sign_mode == \"v2\", otherwise No" or simply
"Required": "Conditional") to reflect that it's only required for sign_mode
"v2"; update the descriptions for both fields (conditional_order_sign_mode and
conditional_order_evm_chain_id) to remain consistent with the new Required
values so integrators are not misled.
In
`@source/json_tables/injective/exchange/v2/MsgBatchLiquidatePositionsResponse.json`:
- Around line 3-6: Add a concise description for the "results" field in the
MsgBatchLiquidatePositionsResponse JSON schema: update the Description for the
Parameter "results" (Type "LiquidatePositionResult array") to something like
"Per-position liquidation outcomes for the batch request" so readers understand
this array contains the liquidation outcome for each position processed in the
batch.
In
`@source/json_tables/injective/exchange/v2/QuerySubaccountRiskProfileResponse.json`:
- Line 5: Add a clear description for the "profile" field in
QuerySubaccountRiskProfileResponse.json: explain that "profile" holds the
SubaccountRiskProfile object and summarize its contents/purpose (e.g., current
risk parameters, limits, margin requirements, and risk-adjustment settings for
the subaccount) so consumers know what data to expect and how to use it when
evaluating a subaccount's trading risk posture.
In `@source/json_tables/injective/oracle/MsgRelaySedaFastPrices.json`:
- Line 5: Add a descriptive text for the sender parameter in
MsgRelaySedaFastPrices.json: update the "Description" field for the "sender"
entry (the same parameter name used in MsgRelayPythProPrices.json) to something
like "sender is the relayer address broadcasting the update" or an equivalent
explanatory phrase so the parameter is no longer empty and matches the style of
the other message specs.
In `@source/json_tables/injective/oracle/QueryPythProPriceStatesResponse.json`:
- Around line 3-5: Update the empty Description for the "price_states" field in
QueryPythProPriceStatesResponse.json: set a concise explanation that
"price_states" is an array of PythProPriceState objects representing the
current/latest price state for each requested asset (including fields like
price, confidence, and timestamp), and note ordering semantics if applicable
(e.g., aligned with request order or sorted by asset id/timestamp). Ensure the
Description string clearly states the element type and the meaning of the array
for generated docs.
In `@source/json_tables/injective/oracle/QuerySedaFastPriceStatesResponse.json`:
- Around line 3-5: Add a clear description for the "price_states" response
field: explain that "price_states" is an array of SedaFastPriceState objects
where each element represents a snapshot of the fast price oracle for a token
(include what key fields in SedaFastPriceState represent, e.g., price value,
timestamp, source/oracle id, and status), note units (e.g., price precision or
quote currency) and any ordering or length guarantees (e.g., sorted descending
by timestamp, contains latest N states). Update the Description for
"price_states" to contain this concise summary so callers understand the array
contents and semantics.
---
Nitpick comments:
In
`@source/json_tables/indexer/injective_derivative_exchange_rpc/StreamPositionsV2Response.json`:
- Around line 12-15: Update the "Description" for the parameter "operation_type"
in StreamPositionsV2Response.json to list the allowed/expected values and
examples; e.g., replace "Position update type" with a short enum-like
description such as "Position update type — allowed values: 'insert', 'update',
'delete' (or other domain-specific values); describes the kind of operation
applied to the position" so API consumers know the exact semantics and examples
of operation_type.
In
`@source/json_tables/indexer/injective_rfq_gw_rpc/RFQGwPrepareRequestType.json`:
- Around line 3-36: Add concise Description entries for the undocumented
parameters client_id, market_id, direction, margin, quantity, worst_price, and
taker_address: specify expected format (e.g., UUID or string pattern) for
client_id and market_id, allowed values for direction (e.g., "buy"|"sell"),
numeric type and units/precision for margin, quantity and worst_price (e.g.,
decimal string, asset units or base/quote, and precision/scale), and the
expected address format for taker_address (e.g., hex EOA). Apply the same
descriptive updates to the corresponding parameter entries in
RFQGwPrepareEip712RequestType.json and
RFQGwPrepareEip712AutoSignRequestType.json so integrators know required formats,
units and valid values.
In
`@source/json_tables/indexer/injective_tc_derivatives_rpc/StreamPositionsResponse.json`:
- Around line 12-15: Update the "Description" for the Parameter "operation_type"
in StreamPositionsResponse.json to enumerate valid values and give examples so
consumers know expected strings; reference the operation_type field and either
list the allowed tokens (e.g., "insert", "update", "delete", "snapshot") or
indicate that the schema uses an enum and show the possible values, and if
applicable mention whether values are case-sensitive or have synonyms.
In
`@source/json_tables/injective/exchange/v2/DerivativeMarketParamUpdateProposal.json`:
- Around line 102-106: Update DerivativeMarketParamUpdateProposal.json to
document the intended mapping between the market boolean cross_margin_eligible
and the tri-state enum CrossMarginEligibility used by cross_margin_eligibility
(refer to MsgUpdateDerivativeMarket for context); specify that
cross_margin_eligible == true maps to CM_ELIGIBILITY_ELIGIBLE,
cross_margin_eligible == false maps to CM_ELIGIBILITY_INELIGIBLE, and
absent/null should map to CM_ELIGIBILITY_UNSPECIFIED, and also note the reverse
mapping rule when reading proposals back into market bools
(CM_ELIGIBILITY_ELIGIBLE -> true, CM_ELIGIBILITY_INELIGIBLE -> false,
CM_ELIGIBILITY_UNSPECIFIED -> treat as unset/null).
In `@source/json_tables/injective/oracle/MsgRelayBandRates.json`:
- Around line 1-32: The JSON schema for MsgRelayBandRates is missing
descriptions for all parameters; update the entries for "relayer", "symbols",
"rates", "resolve_times", and "requestIDs" to include concise descriptions
explaining their purpose (e.g., relayer: address submitting rates; symbols: list
of asset symbols being reported; rates: reported price values corresponding to
symbols; resolve_times: UNIX timestamps when each rate was resolved; requestIDs:
band/oracle request identifiers matching each symbol/rate), so each parameter
clearly documents expected value, format, and relation to the others.
In `@source/json_tables/injective/oracle/MsgRequestBandIBCRates.json`:
- Around line 1-14: Update the JSON parameter entries in
MsgRequestBandIBCRates.json by adding clear, concise descriptions for the
"sender" and "request_id" fields: for "sender" describe it as the bech32 address
(or account) initiating the IBC Band rate request, and for "request_id" describe
it as the unique unsigned 64-bit identifier used to correlate this request with
its response and retries; ensure the "Description" values for the objects
referencing "sender" and "request_id" are non-empty, accurate, and written
consistently with the rest of the JSON docs.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: eece3f3e-56fb-4f41-92cd-82bf204bf319
📒 Files selected for processing (95)
MakefileREADME.mdsource/includes/_binaryoptions.mdsource/includes/_chainstream.mdsource/includes/_changelog.mdsource/includes/_derivatives.mdsource/includes/_derivativesrpc.mdsource/includes/_errors.mdsource/includes/_insurance.mdsource/json_tables/errors/exchange_errors.jsonsource/json_tables/errors/hyperlane_errors.jsonsource/json_tables/errors/injective_errors.jsonsource/json_tables/errors/ism_errors.jsonsource/json_tables/errors/oracle_errors.jsonsource/json_tables/errors/post_dispatch_errors.jsonsource/json_tables/errors/warp_errors.jsonsource/json_tables/indexer/event_provider_api/StreamABCIEventsRequest.jsonsource/json_tables/indexer/event_provider_api/StreamABCIEventsResponse.jsonsource/json_tables/indexer/event_provider_api/StreamedRawBlock.jsonsource/json_tables/indexer/injective_accounts_rpc/DerivativeLimitOrder.jsonsource/json_tables/indexer/injective_chart_rpc/DerivativeMarketHistoryRequest.jsonsource/json_tables/indexer/injective_chart_rpc/SpotMarketHistoryRequest.jsonsource/json_tables/indexer/injective_derivative_exchange_rpc/DerivativeLimitOrder.jsonsource/json_tables/indexer/injective_derivative_exchange_rpc/StreamPositionsV2Response.jsonsource/json_tables/indexer/injective_rfq_gw_rpc/PrepareAutoSignResponse.jsonsource/json_tables/indexer/injective_rfq_gw_rpc/PrepareEip712AutoSignRequest.jsonsource/json_tables/indexer/injective_rfq_gw_rpc/PrepareEip712AutoSignResponse.jsonsource/json_tables/indexer/injective_rfq_gw_rpc/PrepareEip712Request.jsonsource/json_tables/indexer/injective_rfq_gw_rpc/PrepareEip712Response.jsonsource/json_tables/indexer/injective_rfq_gw_rpc/PrepareRequest.jsonsource/json_tables/indexer/injective_rfq_gw_rpc/PrepareResponse.jsonsource/json_tables/indexer/injective_rfq_gw_rpc/RFQGwPrepareEip712AutoSignRequestType.jsonsource/json_tables/indexer/injective_rfq_gw_rpc/RFQGwPrepareEip712RequestType.jsonsource/json_tables/indexer/injective_rfq_gw_rpc/RFQGwPrepareRequestType.jsonsource/json_tables/indexer/injective_rfq_rpc/ConditionalOrderInput.jsonsource/json_tables/indexer/injective_rfq_rpc/ConditionalOrderResponseType.jsonsource/json_tables/indexer/injective_rfq_rpc/CreateConditionalOrderRequest.jsonsource/json_tables/indexer/injective_rfq_rpc/MakerAuth.jsonsource/json_tables/indexer/injective_rfq_rpc/MakerChallenge.jsonsource/json_tables/indexer/injective_rfq_rpc/MakerStreamResponse.jsonsource/json_tables/indexer/injective_rfq_rpc/MakerStreamStreamingRequest.jsonsource/json_tables/indexer/injective_rfq_rpc/RFQProcessedQuoteType.jsonsource/json_tables/indexer/injective_rfq_rpc/RFQQuoteType.jsonsource/json_tables/indexer/injective_rfq_rpc/RFQSettlementMakerUpdate.jsonsource/json_tables/indexer/injective_rfq_rpc/RFQSettlementType.jsonsource/json_tables/indexer/injective_rfq_rpc/StreamError.jsonsource/json_tables/indexer/injective_rfq_rpc/TakerStreamStreamingRequest.jsonsource/json_tables/indexer/injective_tc_derivatives_rpc/DerivativeLimitOrder.jsonsource/json_tables/indexer/injective_tc_derivatives_rpc/StreamPositionsResponse.jsonsource/json_tables/indexer/injective_tc_derivatives_rpc/StreamTradesRequest.jsonsource/json_tables/indexer/injective_tc_derivatives_rpc/TCDerivativeOrderHistoryType.jsonsource/json_tables/indexer/injective_tc_derivatives_rpc/TCDerivativeTrade.jsonsource/json_tables/indexer/injective_tc_derivatives_rpc/TradesRequest.jsonsource/json_tables/injective/exchange/v2/CrossMarginEligibility.jsonsource/json_tables/injective/exchange/v2/CrossMarginParams.jsonsource/json_tables/injective/exchange/v2/DerivativeMarket.jsonsource/json_tables/injective/exchange/v2/DerivativeMarketParamUpdateProposal.jsonsource/json_tables/injective/exchange/v2/DerivativeMarketSettlementInfo.jsonsource/json_tables/injective/exchange/v2/ExpiryFuturesMarketLaunchProposal.jsonsource/json_tables/injective/exchange/v2/GenesisState.jsonsource/json_tables/injective/exchange/v2/LiquidatePositionData.jsonsource/json_tables/injective/exchange/v2/LiquidatePositionResult.jsonsource/json_tables/injective/exchange/v2/MsgBatchLiquidatePositions.jsonsource/json_tables/injective/exchange/v2/MsgBatchLiquidatePositionsResponse.jsonsource/json_tables/injective/exchange/v2/MsgInstantExpiryFuturesMarketLaunch.jsonsource/json_tables/injective/exchange/v2/MsgInstantPerpetualMarketLaunch.jsonsource/json_tables/injective/exchange/v2/MsgLiquidateCrossMarginPool.jsonsource/json_tables/injective/exchange/v2/MsgSetDelegationTransferReceivers.jsonsource/json_tables/injective/exchange/v2/MsgUpdateDerivativeMarket.jsonsource/json_tables/injective/exchange/v2/MsgUpdateSubaccountRiskProfile.jsonsource/json_tables/injective/exchange/v2/Params.jsonsource/json_tables/injective/exchange/v2/PerpetualMarketLaunchProposal.jsonsource/json_tables/injective/exchange/v2/QueryCrossMarginPoolSnapshotRequest.jsonsource/json_tables/injective/exchange/v2/QueryCrossMarginPoolSnapshotResponse.jsonsource/json_tables/injective/exchange/v2/QuerySubaccountEffectivePositionInMarketResponse.jsonsource/json_tables/injective/exchange/v2/QuerySubaccountPositionInMarketResponse.jsonsource/json_tables/injective/exchange/v2/QuerySubaccountRiskProfileRequest.jsonsource/json_tables/injective/exchange/v2/QuerySubaccountRiskProfileResponse.jsonsource/json_tables/injective/exchange/v2/ReservationPolicy.jsonsource/json_tables/injective/exchange/v2/RiskMode.jsonsource/json_tables/injective/exchange/v2/SubaccountRiskProfile.jsonsource/json_tables/injective/exchange/v2/SubaccountRiskProfileRecord.jsonsource/json_tables/injective/oracle/GenesisState.jsonsource/json_tables/injective/oracle/MsgRelayBandRates.jsonsource/json_tables/injective/oracle/MsgRelayPythProPrices.jsonsource/json_tables/injective/oracle/MsgRelaySedaFastPrices.jsonsource/json_tables/injective/oracle/MsgRequestBandIBCRates.jsonsource/json_tables/injective/oracle/Params.jsonsource/json_tables/injective/oracle/PythProPriceState.jsonsource/json_tables/injective/oracle/QueryPythProPriceStatesResponse.jsonsource/json_tables/injective/oracle/QuerySedaFastPriceStatesResponse.jsonsource/json_tables/injective/oracle/SedaFastParams.jsonsource/json_tables/injective/oracle/SedaFastPriceState.jsonsource/json_tables/injective/oracle/v1beta1/OracleType.jsonsource/json_tables/injective/stream/v2/DerivativeTrade.json
💤 Files with no reviewable changes (4)
- source/json_tables/errors/ism_errors.json
- source/json_tables/errors/hyperlane_errors.json
- source/json_tables/errors/warp_errors.json
- source/json_tables/errors/post_dispatch_errors.json
Comment on lines
+73
to
+75
| ``` | ||
| make update-all-proto-related-files | ||
| ``` |
There was a problem hiding this comment.
Add language identifiers to fenced code blocks.
Line 73, Line 87, and Line 112 use unlabeled fenced blocks, which triggers markdownlint MD040.
Suggested fix
-```
+```bash
make update-all-proto-related-files- +bash
make refresh-examples
-```
+```bash
./slate.sh serve
</details>
Also applies to: 87-89, 112-114
<details>
<summary>🧰 Tools</summary>
<details>
<summary>🪛 markdownlint-cli2 (0.22.1)</summary>
[warning] 73-73: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
</details>
<details>
<summary>🤖 Prompt for AI Agents</summary>
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @README.md around lines 73 - 75, The README contains unlabeled fenced code
blocks for commands (make update-all-proto-related-files, make refresh-examples,
./slate.sh serve) which triggers markdownlint MD040; update each triple-backtick
fence around those command examples to include a language identifier (e.g.,
change tobash) for the blocks that contain those commands (the instances
around the lines referencing make update-all-proto-related-files, make
refresh-examples, and ./slate.sh serve) so the code blocks are labeled and MD040
is resolved.
</details>
<!-- fingerprinting:phantom:triton:hawk -->
<!-- This is an auto-generated comment by CodeRabbit -->
|
|
||
| ## MsgBatchLiquidatePositions | ||
|
|
||
| This message is sent to the chain to liquidate more than one position with a single message. For more details about liquidation check [MsgLiquidatePosition](#chain-exchange-for-derivatives-msgliquidateposition). |
There was a problem hiding this comment.
Fix broken intra-page anchor for MsgLiquidatePosition.
The fragment #chain-exchange-for-derivatives-msgliquidateposition does not match this page’s heading anchor pattern and is flagged as invalid, so this link can break in rendered docs. Point it to the actual generated anchor for the ## MsgLiquidatePosition section.
Suggested fix
-This message is sent to the chain to liquidate more than one position with a single message. For more details about liquidation check [MsgLiquidatePosition](`#chain-exchange-for-derivatives-msgliquidateposition`).
+This message is sent to the chain to liquidate more than one position with a single message. For more details about liquidation check [MsgLiquidatePosition](`#derivatives-msgliquidateposition`).📝 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.
Suggested change
| This message is sent to the chain to liquidate more than one position with a single message. For more details about liquidation check [MsgLiquidatePosition](#chain-exchange-for-derivatives-msgliquidateposition). | |
| This message is sent to the chain to liquidate more than one position with a single message. For more details about liquidation check [MsgLiquidatePosition](`#derivatives-msgliquidateposition`). |
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 5845-5845: Link fragments should be valid
(MD051, link-fragments)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@source/includes/_derivatives.md` at line 5845, The intra-page link fragment
for MsgLiquidatePosition is invalid; locate the heading "##
MsgLiquidatePosition" and update the link target from
"`#chain-exchange-for-derivatives-msgliquidateposition`" to the actual generated
anchor for that heading (e.g., the anchor generated from
"MsgLiquidatePosition"); in other words, find the current link referencing
MsgLiquidatePosition and replace its fragment with the exact anchor string
produced for the "## MsgLiquidatePosition" section so the link correctly
navigates to that heading.
Comment on lines
+14
to
+19
| { | ||
| "Parameter": "batch_size", | ||
| "Type": "uint32", | ||
| "Description": "Number of blocks to include in each stream response. The service will have a cap on the batch size, and default to it if it's greater. Once the stream is in sync, the batch size", | ||
| "Required": "Yes" | ||
| }, |
There was a problem hiding this comment.
Incomplete batch_size description.
The description is truncated mid-sentence ("...Once the stream is in sync, the batch size"), so it will render as a dangling fragment in the generated table. Please complete the sentence describing the in-sync behavior.
📝 Suggested fix (complete the sentence)
- "Description": "Number of blocks to include in each stream response. The service will have a cap on the batch size, and default to it if it's greater. Once the stream is in sync, the batch size",
+ "Description": "Number of blocks to include in each stream response. The service will have a cap on the batch size, and default to it if it's greater. Once the stream is in sync, the batch size will be reduced to 1 so each new block is delivered as it is produced.",📝 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.
Suggested change
| { | |
| "Parameter": "batch_size", | |
| "Type": "uint32", | |
| "Description": "Number of blocks to include in each stream response. The service will have a cap on the batch size, and default to it if it's greater. Once the stream is in sync, the batch size", | |
| "Required": "Yes" | |
| }, | |
| { | |
| "Parameter": "batch_size", | |
| "Type": "uint32", | |
| "Description": "Number of blocks to include in each stream response. The service will have a cap on the batch size, and default to it if it's greater. Once the stream is in sync, the batch size will be reduced to 1 so each new block is delivered as it is produced.", | |
| "Required": "Yes" | |
| }, |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@source/json_tables/indexer/event_provider_api/StreamABCIEventsRequest.json`
around lines 14 - 19, The "Description" for the parameter "batch_size" in
StreamABCIEventsRequest.json is truncated; confirm the exact in-sync behavior
with the author or spec, then update the Description to a complete sentence that
clearly states what happens once the stream is in sync (for example: "Once the
stream is in sync, the batch_size controls how many blocks are returned per
response, subject to the service cap"), keeping the "Parameter", "Type", and
"Required" fields unchanged; ensure the new text reads as a complete sentence
and matches the confirmed behavior.
Comment on lines
+14
to
25
| { | ||
| "Parameter": "sign_mode", | ||
| "Type": "string", | ||
| "Description": "Signature scheme used for the conditional order: \"v1\" (raw JSON keccak256) or \"v2\" (EIP-712). Defaults to \"v1\" when omitted, for backward compatibility with pre-EIP-712 clients.", | ||
| "Required": "Yes" | ||
| }, | ||
| { | ||
| "Parameter": "evm_chain_id", | ||
| "Type": "uint64", | ||
| "Description": "EVM chain ID embedded in the EIP-712 domain. Required when sign_mode is \"v2\"; ignored otherwise. Must match one of the indexer's configured chain IDs.", | ||
| "Required": "Yes" | ||
| } |
There was a problem hiding this comment.
Required flags contradict the field descriptions.
Both new fields are marked "Required": "Yes", but their descriptions state otherwise:
sign_mode"Defaults to"v1"when omitted" — i.e. optional, not required.evm_chain_idis "Required when sign_mode is"v2"; ignored otherwise" — conditionally required, not always required.
As written, the table tells consumers they must always send both, which is inaccurate and conflicts with the backward-compatibility behavior described.
📝 Proposed doc fix
{
"Parameter": "sign_mode",
"Type": "string",
"Description": "Signature scheme used for the conditional order: \"v1\" (raw JSON keccak256) or \"v2\" (EIP-712). Defaults to \"v1\" when omitted, for backward compatibility with pre-EIP-712 clients.",
- "Required": "Yes"
+ "Required": "No"
},
{
"Parameter": "evm_chain_id",
"Type": "uint64",
"Description": "EVM chain ID embedded in the EIP-712 domain. Required when sign_mode is \"v2\"; ignored otherwise. Must match one of the indexer's configured chain IDs.",
- "Required": "Yes"
+ "Required": "Conditional (required when sign_mode is \"v2\")"
}📝 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.
Suggested change
| { | |
| "Parameter": "sign_mode", | |
| "Type": "string", | |
| "Description": "Signature scheme used for the conditional order: \"v1\" (raw JSON keccak256) or \"v2\" (EIP-712). Defaults to \"v1\" when omitted, for backward compatibility with pre-EIP-712 clients.", | |
| "Required": "Yes" | |
| }, | |
| { | |
| "Parameter": "evm_chain_id", | |
| "Type": "uint64", | |
| "Description": "EVM chain ID embedded in the EIP-712 domain. Required when sign_mode is \"v2\"; ignored otherwise. Must match one of the indexer's configured chain IDs.", | |
| "Required": "Yes" | |
| } | |
| { | |
| "Parameter": "sign_mode", | |
| "Type": "string", | |
| "Description": "Signature scheme used for the conditional order: \"v1\" (raw JSON keccak256) or \"v2\" (EIP-712). Defaults to \"v1\" when omitted, for backward compatibility with pre-EIP-712 clients.", | |
| "Required": "No" | |
| }, | |
| { | |
| "Parameter": "evm_chain_id", | |
| "Type": "uint64", | |
| "Description": "EVM chain ID embedded in the EIP-712 domain. Required when sign_mode is \"v2\"; ignored otherwise. Must match one of the indexer's configured chain IDs.", | |
| "Required": "Conditional (required when sign_mode is \"v2\")" | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@source/json_tables/indexer/injective_rfq_rpc/CreateConditionalOrderRequest.json`
around lines 14 - 25, Update the "Required" flags in
CreateConditionalOrderRequest.json to match the descriptions: set "sign_mode"
Required to "No" (since it defaults to "v1" when omitted) and set "evm_chain_id"
Required to "No (required when sign_mode is \"v2\")" to indicate conditional
requirement; ensure the entries for the parameters "sign_mode" and
"evm_chain_id" reflect these exact text changes so consumers see optional vs
conditional requirement correctly.
Comment on lines
+26
to
37
| { | ||
| "Parameter": "conditional_order_sign_mode", | ||
| "Type": "string", | ||
| "Description": "Signature scheme for the conditional order: \"v1\" (raw JSON keccak256) or \"v2\" (EIP-712). Defaults to \"v1\" when omitted, for backward compatibility with pre-EIP-712 clients.", | ||
| "Required": "Yes" | ||
| }, | ||
| { | ||
| "Parameter": "conditional_order_evm_chain_id", | ||
| "Type": "uint64", | ||
| "Description": "EVM chain ID embedded in the EIP-712 domain for the conditional order. Required when conditional_order_sign_mode is \"v2\".", | ||
| "Required": "Yes" | ||
| } |
There was a problem hiding this comment.
Required flags contradict the field descriptions.
conditional_order_sign_mode is documented as defaulting to "v1" when omitted, which means it is optional — but it is marked "Required": "Yes". Likewise conditional_order_evm_chain_id is only required when conditional_order_sign_mode is "v2" (per its own description), so an unconditional "Yes" is misleading. Readers integrating against this RPC will assume both must always be sent.
📝 Proposed fix
{
"Parameter": "conditional_order_sign_mode",
"Type": "string",
"Description": "Signature scheme for the conditional order: \"v1\" (raw JSON keccak256) or \"v2\" (EIP-712). Defaults to \"v1\" when omitted, for backward compatibility with pre-EIP-712 clients.",
- "Required": "Yes"
+ "Required": "No"
},
{
"Parameter": "conditional_order_evm_chain_id",
"Type": "uint64",
"Description": "EVM chain ID embedded in the EIP-712 domain for the conditional order. Required when conditional_order_sign_mode is \"v2\".",
- "Required": "Yes"
+ "Required": "Conditional (required when conditional_order_sign_mode is \"v2\")"
}📝 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.
Suggested change
| { | |
| "Parameter": "conditional_order_sign_mode", | |
| "Type": "string", | |
| "Description": "Signature scheme for the conditional order: \"v1\" (raw JSON keccak256) or \"v2\" (EIP-712). Defaults to \"v1\" when omitted, for backward compatibility with pre-EIP-712 clients.", | |
| "Required": "Yes" | |
| }, | |
| { | |
| "Parameter": "conditional_order_evm_chain_id", | |
| "Type": "uint64", | |
| "Description": "EVM chain ID embedded in the EIP-712 domain for the conditional order. Required when conditional_order_sign_mode is \"v2\".", | |
| "Required": "Yes" | |
| } | |
| { | |
| "Parameter": "conditional_order_sign_mode", | |
| "Type": "string", | |
| "Description": "Signature scheme for the conditional order: \"v1\" (raw JSON keccak256) or \"v2\" (EIP-712). Defaults to \"v1\" when omitted, for backward compatibility with pre-EIP-712 clients.", | |
| "Required": "No" | |
| }, | |
| { | |
| "Parameter": "conditional_order_evm_chain_id", | |
| "Type": "uint64", | |
| "Description": "EVM chain ID embedded in the EIP-712 domain for the conditional order. Required when conditional_order_sign_mode is \"v2\".", | |
| "Required": "Conditional (required when conditional_order_sign_mode is \"v2\")" | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@source/json_tables/indexer/injective_rfq_rpc/TakerStreamStreamingRequest.json`
around lines 26 - 37, The "Required" flags are incorrect: set
"conditional_order_sign_mode" to optional ("Required": "No") because its
description states it defaults to "v1" when omitted, and change
"conditional_order_evm_chain_id" to be conditionally required (e.g., "Required":
"Yes when conditional_order_sign_mode == \"v2\", otherwise No" or simply
"Required": "Conditional") to reflect that it's only required for sign_mode
"v2"; update the descriptions for both fields (conditional_order_sign_mode and
conditional_order_evm_chain_id) to remain consistent with the new Required
values so integrators are not misled.
Comment on lines
+3
to
+6
| "Parameter": "results", | ||
| "Type": "LiquidatePositionResult array", | ||
| "Description": "" | ||
| } |
There was a problem hiding this comment.
Fill the empty response field description.
Line 5 leaves Description blank for results, which makes the schema ambiguous for readers. Add a short description (e.g., “per-position liquidation outcomes for the batch request”).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@source/json_tables/injective/exchange/v2/MsgBatchLiquidatePositionsResponse.json`
around lines 3 - 6, Add a concise description for the "results" field in the
MsgBatchLiquidatePositionsResponse JSON schema: update the Description for the
Parameter "results" (Type "LiquidatePositionResult array") to something like
"Per-position liquidation outcomes for the batch request" so readers understand
this array contains the liquidation outcome for each position processed in the
batch.
| { | ||
| "Parameter": "profile", | ||
| "Type": "SubaccountRiskProfile", | ||
| "Description": "" |
There was a problem hiding this comment.
Add description for the profile parameter.
The description field is empty. Documentation should explain what the SubaccountRiskProfile contains or its purpose.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@source/json_tables/injective/exchange/v2/QuerySubaccountRiskProfileResponse.json`
at line 5, Add a clear description for the "profile" field in
QuerySubaccountRiskProfileResponse.json: explain that "profile" holds the
SubaccountRiskProfile object and summarize its contents/purpose (e.g., current
risk parameters, limits, margin requirements, and risk-adjustment settings for
the subaccount) so consumers know what data to expect and how to use it when
evaluating a subaccount's trading risk posture.
| { | ||
| "Parameter": "sender", | ||
| "Type": "string", | ||
| "Description": "", |
There was a problem hiding this comment.
Add a description for the sender parameter.
The sender parameter has an empty description. For consistency with MsgRelayPythProPrices.json, consider adding a description such as "sender is the relayer address broadcasting the update" or similar explanatory text.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@source/json_tables/injective/oracle/MsgRelaySedaFastPrices.json` at line 5,
Add a descriptive text for the sender parameter in MsgRelaySedaFastPrices.json:
update the "Description" field for the "sender" entry (the same parameter name
used in MsgRelayPythProPrices.json) to something like "sender is the relayer
address broadcasting the update" or an equivalent explanatory phrase so the
parameter is no longer empty and matches the style of the other message specs.
Comment on lines
+3
to
+5
| "Parameter": "price_states", | ||
| "Type": "PythProPriceState array", | ||
| "Description": "" |
There was a problem hiding this comment.
Fill the empty response field description.
Line 5 leaves price_states undocumented, which degrades the generated docs for this new endpoint. Add a short description for the array semantics.
✍️ Proposed doc fix
{
"Parameter": "price_states",
"Type": "PythProPriceState array",
- "Description": ""
+ "Description": "List of persisted PythPro price states."
}📝 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.
Suggested change
| "Parameter": "price_states", | |
| "Type": "PythProPriceState array", | |
| "Description": "" | |
| "Parameter": "price_states", | |
| "Type": "PythProPriceState array", | |
| "Description": "List of persisted PythPro price states." |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@source/json_tables/injective/oracle/QueryPythProPriceStatesResponse.json`
around lines 3 - 5, Update the empty Description for the "price_states" field in
QueryPythProPriceStatesResponse.json: set a concise explanation that
"price_states" is an array of PythProPriceState objects representing the
current/latest price state for each requested asset (including fields like
price, confidence, and timestamp), and note ordering semantics if applicable
(e.g., aligned with request order or sorted by asset id/timestamp). Ensure the
Description string clearly states the element type and the meaning of the array
for generated docs.
Comment on lines
+3
to
+5
| "Parameter": "price_states", | ||
| "Type": "SedaFastPriceState array", | ||
| "Description": "" |
There was a problem hiding this comment.
Fill the empty response field description.
Line 5 leaves price_states undocumented, so readers won’t know what this array contains without opening another table.
✍️ Proposed doc fix
{
"Parameter": "price_states",
"Type": "SedaFastPriceState array",
- "Description": ""
+ "Description": "List of persisted SEDA Fast price states."
}📝 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.
Suggested change
| "Parameter": "price_states", | |
| "Type": "SedaFastPriceState array", | |
| "Description": "" | |
| "Parameter": "price_states", | |
| "Type": "SedaFastPriceState array", | |
| "Description": "List of persisted SEDA Fast price states." |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@source/json_tables/injective/oracle/QuerySedaFastPriceStatesResponse.json`
around lines 3 - 5, Add a clear description for the "price_states" response
field: explain that "price_states" is an array of SedaFastPriceState objects
where each element represents a snapshot of the fast price oracle for a token
(include what key fields in SedaFastPriceState represent, e.g., price value,
timestamp, source/oracle id, and status), note units (e.g., price precision or
quote currency) and any ordering or length guarantees (e.g., sorted descending
by timestamp, contains latest N states). Update the Description for
"price_states" to contain this concise summary so callers understand the array
contents and semantics.
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
2 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.
Solves IC-1056
Summary by CodeRabbit
New Features
Documentation
Chores