fix: update swagger script #270
Conversation
Run with `make proto-swagger-gen` Edits: - Fix path for some query.proto files - Add all eligible modules to config.json - Remove any unused modules from it - Include `exocore` modules in the script
WalkthroughThis pull request encompasses a comprehensive update to the project's API documentation and gRPC service definitions, transitioning from "Evmos Chain" to "Exocore". The changes primarily involve renaming project references, updating API URLs, and standardizing endpoint paths with version Changes
Suggested labels
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI ⛔ Files ignored due to path filters (4)
📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (3)
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
proto/exocore/slash/v1/query.proto (1)
Line range hint
6-6: Remove scaffolding comment.The comment
// this line is used by starport scaffolding # 1appears to be an artifact from code generation and should be removed.-// this line is used by starport scaffolding # 1client/docs/config.json (1)
Line range hint
1-227: Consider adding API versioning documentation.While the configuration is well-structured, it would be beneficial to add documentation about API versioning strategy, especially since we're mixing v1 and v1beta1 endpoints.
Consider adding a comment block at the top of the file explaining:
- The versioning strategy for different modules
- When to use v1 vs v1beta1
- Migration guidelines for deprecated endpoints
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (12)
x/avs/types/query.pb.gois excluded by!**/*.pb.gox/avs/types/query.pb.gw.gois excluded by!**/*.pb.gw.gox/epochs/types/query.pb.gois excluded by!**/*.pb.gox/epochs/types/query.pb.gw.gois excluded by!**/*.pb.gw.gox/feedistribution/types/query.pb.gois excluded by!**/*.pb.gox/feedistribution/types/query.pb.gw.gois excluded by!**/*.pb.gw.gox/oracle/types/query.pb.gois excluded by!**/*.pb.gox/oracle/types/query.pb.gw.gois excluded by!**/*.pb.gw.gox/reward/types/query.pb.gois excluded by!**/*.pb.gox/reward/types/query.pb.gw.gois excluded by!**/*.pb.gw.gox/slash/types/query.pb.gois excluded by!**/*.pb.gox/slash/types/query.pb.gw.gois excluded by!**/*.pb.gw.go
📒 Files selected for processing (8)
client/docs/config.json(2 hunks)proto/exocore/avs/v1/query.proto(1 hunks)proto/exocore/dogfood/v1/query.proto(1 hunks)proto/exocore/epochs/v1/query.proto(1 hunks)proto/exocore/feedistribution/v1/query.proto(1 hunks)proto/exocore/oracle/v1/query.proto(1 hunks)proto/exocore/reward/v1/query.proto(1 hunks)proto/exocore/slash/v1/query.proto(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- proto/exocore/oracle/v1/query.proto
🔇 Additional comments (10)
proto/exocore/reward/v1/query.proto (1)
13-13: LGTM! Verify consistency with other endpoints.
The updated endpoint path follows RESTful conventions and correctly includes version numbering. The structure /exocore/reward/v1/params aligns with the package name and versioning.
Let's verify the consistency of endpoint paths across the codebase:
✅ Verification successful
LGTM! Endpoint path structure is consistent across the codebase.
The updated endpoint path /exocore/reward/v1/params follows the consistent pattern used throughout the codebase. All exocore module endpoints follow the same structure: /exocore/{module}/v1/{endpoint}, including slash, operator, oracle, reward, and other modules. The version (v1) is correctly placed in the path, matching the package versioning.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for inconsistent API endpoint paths in proto files
# Expected pattern: /exocore/{module}/v1/{endpoint}
# Search for all HTTP endpoint definitions in proto files
rg -t proto 'option \(google\.api\.http\).*= ".*"'
Length of output: 82
Script:
#!/bin/bash
# Search for all HTTP endpoint definitions in protobuf files
rg 'option \(google\.api\.http\)' --type-add 'proto:*.proto' -t proto
Length of output: 15378
proto/exocore/slash/v1/query.proto (1)
14-14: LGTM! Endpoint structure is consistent.
The updated endpoint path /exocore/slash/v1/params follows the established pattern and correctly includes version numbering.
proto/exocore/epochs/v1/query.proto (2)
17-17: LGTM: Endpoint path correctly updated for EpochInfos
The endpoint path has been properly updated to reflect the epochs module instead of dogfood, maintaining the v1 version prefix.
21-21: LGTM: CurrentEpoch endpoint updated with proper path parameter
The endpoint path has been correctly updated to:
- Use the epochs module instead of dogfood
- Include the {identifier} path parameter which matches the request message field
proto/exocore/avs/v1/query.proto (1)
79-79: LGTM: Endpoint paths correctly standardized
The following endpoints have been properly updated to include the v1 version:
- QueryAVSInfo
- QueryAVSAddrByChainID
- QuerySubmitTaskResult
- QueryChallengeInfo
Also applies to: 87-87, 91-91, 95-95
proto/exocore/dogfood/v1/query.proto (1)
16-16: LGTM: All endpoint paths correctly standardized
The following endpoints have been properly updated to include the v1 version while maintaining consistent patterns:
- Params
- OptOutsToFinish
- OperatorOptOutFinishEpoch
- UndelegationsToMature
- UndelegationMaturityEpoch
- QueryValidator
All path parameters correctly match their corresponding request message fields.
Also applies to: 21-21, 26-26, 31-31, 36-36, 41-41
client/docs/config.json (4)
4-4: LGTM: Title update aligns with project rebranding.
The title change from "Evmos Chain" to "Exocore" correctly reflects the project rebranding.
207-227: LGTM: Additional module configurations are properly structured.
The configurations for interchain accounts, consensus, and reward modules follow the established pattern with appropriate operation ID renaming to prevent conflicts.
128-132: Verify the staking API endpoint change.
The staking API endpoint has been changed from staking/v1beta1/query to tx/v1beta1/service. This is a significant change that could affect existing integrations.
199-205: Verify the upgrade API path exclusion.
The exclusion of the upgraded consensus state endpoint needs verification to ensure it doesn't break existing functionality.
✅ Verification successful
Exclusion of upgraded consensus state endpoint is safe
The endpoint /cosmos/upgrade/v1beta1/upgraded_consensus_state/{last_height} is being excluded from the Cosmos upgrade module's swagger documentation, while a different endpoint /ibc/core/client/v1/upgraded_consensus_states remains available. This is safe because:
- The excluded endpoint is specific to the Cosmos upgrade module's internal consensus state
- The IBC client's upgraded consensus state endpoint remains accessible
- No client-side code references were found that depend on the excluded endpoint
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the impact of excluding the upgraded consensus state endpoint
# Check for any direct references to the excluded endpoint
rg -l "upgraded_consensus_state" --type ts --type js --type md
# Check if there are any integration tests using this endpoint
rg -l "upgraded_consensus_state" --type test --type spec
Length of output: 148
Script:
#!/bin/bash
# Let's try a more comprehensive search approach
# Search for any references to upgraded_consensus_state in all files
rg -l "upgraded_consensus_state"
# Check the swagger file content to understand the endpoint usage
cat "./tmp-swagger-gen/cosmos/upgrade/v1beta1/query.swagger.json" || true
# Look for any upgrade-related API usage patterns
rg -l "upgrade.*api|upgrade.*endpoint" --type ts --type js
# Check for test files with different extensions
fd -e test.ts -e test.js -e spec.ts -e spec.js | xargs rg -l "upgraded_consensus_state" || true
Length of output: 466
Script:
#!/bin/bash
# Let's examine the swagger.json file to understand the endpoint context
cat "client/docs/swagger-ui/swagger.json" | grep -A 10 -B 10 "upgraded_consensus_state" || true
# Check the content of config.json to understand the full context
cat "client/docs/config.json" | grep -A 10 -B 10 "upgraded_consensus_state" || true
# Look for any upgrade-related client code
rg "upgrade" --type ts --type js -A 5 -B 5
Length of output: 8374
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (2)
x/avs/types/query.pb.gois excluded by!**/*.pb.gox/avs/types/query.pb.gw.gois excluded by!**/*.pb.gw.go
📒 Files selected for processing (2)
proto/exocore/avs/v1/query.proto(1 hunks)scripts/protoc-swagger-gen.sh(1 hunks)
🔇 Additional comments (2)
scripts/protoc-swagger-gen.sh (1)
15-15: LGTM! Verify proto directory structure
The addition of exocore proto files to the Swagger generation process aligns with the PR objectives.
Let's verify the proto directory structure:
✅ Verification successful
Proto directory structure verified successfully
The proto/exocore directory exists and contains a comprehensive set of proto files organized in modules like appchain, assets, avs, delegation, etc., which confirms the path used in the script is valid.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify proto directory structure exists and contains expected files
# Check if proto/exocore directory exists and contains proto files
if [ -d "./proto/exocore" ]; then
echo "Directory ./proto/exocore exists"
find ./proto/exocore -name "*.proto" -type f
else
echo "Error: Directory ./proto/exocore not found"
exit 1
fi
Length of output: 2890
proto/exocore/avs/v1/query.proto (1)
83-83: Standardize the endpoint path for QueryAVSTaskInfo
The endpoint path /exocore/avs/v1/GetAVSTaskInfoReq is inconsistent with other endpoints as it uses a request message name instead of an operation name.
Consider updating to:
- option (google.api.http).get = "/exocore/avs/v1/GetAVSTaskInfoReq";
+ option (google.api.http).get = "/exocore/avs/v1/task_info";
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
MaxMustermann2
requested review from
bwhour,
adu-web3,
cloud8little,
trestinlsd,
mikebraver,
TimmyExogenous and
leonz789
Run with
make proto-swagger-genEdits:
exocoremodules in the scriptDescription
Closes #XXX
Summary by CodeRabbit
New Features
Improvements
Bug Fixes
Documentation