feat(dashmate): add protocol version to the status command

[shumkov]

Issue being fixed or feature implemented

Users want to see the current and desired protocol versions

What was done?

• Added desired and current protocol versions to the dashmate status platform command.

How Has This Been Tested?

Running the command locally

Breaking Changes

None

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

Summary by CodeRabbit

• New Features

  • Added Protocol Version and Desired Protocol Version to platform status details.
  • Enhanced platform monitoring with additional API data for improved operational insights.

• Bug Fixes

  • Updated test cases to ensure accuracy in protocol versioning assertions.

• Tests

  • Expanded test coverage for the getPlatformScope function to include new properties and scenarios.

[coderabbitai]

Walkthrough

The changes in this pull request enhance the PlatformStatusCommand class and the getPlatformScopeFactory function by introducing new properties related to protocol versions. Specifically, the plain object in PlatformStatusCommand now includes Protocol Version and Desired Protocol Version, initialized to 'n/a'. Additionally, the getTenderdashInfo function fetches these values from a new API endpoint and integrates them into the platform's status output. The test suite is updated to reflect these changes, ensuring comprehensive coverage of the new functionality.

Changes

File Path	Change Summary
packages/dashmate/src/commands/status/platform.js	Added properties Protocol Version and Desired Protocol Version to PlatformStatusCommand. Extracted values from tenderdash object in runWithDependencies method.
packages/dashmate/src/status/scopes/platform.js	Modified getPlatformScopeFactory to include new properties protocolVersion and desiredProtocolVersion in getTenderdashInfo. Updated API call structure for additional data.
packages/dashmate/test/unit/status/scopes/platform.spec.js	Updated test suite for getPlatformScopeFactory to include new properties in mockStatus and expectedScope. Adjusted test cases for new protocol versioning information.

Possibly related PRs

• feat(dashmate): validate external IP #2183: The changes in this PR enhance the getPlatformScopeFactory function by adding protocolVersion and desiredProtocolVersion properties, which are directly related to the new properties added in the PlatformStatusCommand class in the main PR.
• fix(dashmate): invalid drive status check #2248: This PR modifies the PlatformStatusCommand class to improve the logic for determining the platform status, which is relevant to the changes made in the main PR regarding the PlatformStatusCommand class.
• fix(dashmate): invalid platform version in the status command #2249: This PR updates the PlatformStatusCommand class to correctly assign the platform version, which is related to the changes made in the main PR that also involve the PlatformStatusCommand class.

Suggested labels

dashmate

Suggested reviewers

• QuantumExplorer
• pshenmic

Poem

In the land of code where bunnies play,
New properties hop in, brightening the day.
Protocol versions join the fun,
Enhancing the status, one by one.
With tests all set, let’s leap and cheer,
For a platform that’s better, let’s give a cheer! 🐇✨

---

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?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

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)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 2

🧹 Outside diff range and nitpick comments (1)

packages/dashmate/src/commands/status/platform.js (1)

107-108: LGTM: Protocol version properties correctly assigned with a minor suggestion

The assignment of protocolVersion and desiredProtocolVersion to the plain object is well-implemented and consistent with the existing code structure. The use of the logical OR operator for fallback to 'n/a' is a concise approach.

For consistency with other assignments in this block, consider using the || operator instead of the ternary operator used elsewhere. For example:

plain['Protocol Version'] = protocolVersion || 'n/a';
plain['Desired Protocol Version'] = desiredProtocolVersion || 'n/a';

This change would make the code more uniform with the surrounding assignments.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Files that changed from the base of the PR and between 1c35386 and bfd2b76.

📒 Files selected for processing (3)

• packages/dashmate/src/commands/status/platform.js (3 hunks)
• packages/dashmate/src/status/scopes/platform.js (5 hunks)
• packages/dashmate/test/unit/status/scopes/platform.spec.js (16 hunks)

🧰 Additional context used

📓 Learnings (1)

packages/dashmate/test/unit/status/scopes/platform.spec.js (2)

Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:466-467
Timestamp: 2024-10-18T15:37:21.329Z
Learning: In test files for the dashmate project, such as `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests rather than consolidating them, to increase readability.

Learnt from: shumkov
PR: dashpay/platform#2249
File: packages/dashmate/test/unit/status/scopes/platform.spec.js:77-78
Timestamp: 2024-10-18T15:37:36.387Z
Learning: In `packages/dashmate/test/unit/status/scopes/platform.spec.js`, prefer to keep mocks explicitly in tests to increase readability, rather than refactoring them into shared `beforeEach` blocks or helper functions.

🔇 Additional comments (15)

packages/dashmate/src/commands/status/platform.js (3)

50-51: LGTM: New protocol version properties added correctly

The addition of 'Protocol Version' and 'Desired Protocol Version' properties to the plain object is well-implemented. These new fields are consistent with the existing structure and are appropriately initialized with 'n/a'.

---

97-98: LGTM: Protocol version properties correctly extracted

The extraction of protocolVersion and desiredProtocolVersion from the tenderdash object is well-implemented. It's correctly placed within the existing check for tenderdash.version, ensuring these properties are only accessed when tenderdash data is available.

---

50-51: Summary: Protocol version information successfully added to status command

The changes effectively implement the addition of protocol version information to the PlatformStatusCommand output. The new properties are correctly initialized, extracted from the tenderdash object, and assigned to the plain object for display.

These additions enhance the status command by providing users with visibility into both the current and desired protocol versions, as requested. The implementation is consistent with the existing code structure and follows good practices.

To ensure that these changes are properly integrated and don't introduce any regressions, please run the following verification script:

This script will help ensure that the changes are correctly implemented and that any necessary test updates have been made.

Also applies to: 97-98, 107-108

packages/dashmate/test/unit/status/scopes/platform.spec.js (8)

83-87: LGTM: Addition of protocol_version object

The new protocol_version object in mockStatus correctly reflects the structure of the API response, including p2p, block, and app versions. This addition aligns well with the PR objective of including protocol version information in the status command.

---

102-110: LGTM: Addition of mockAbciInfo object

The new mockAbciInfo object provides appropriate mock data for testing the ABCI info retrieval, including version, app_version, last_block_height, and last_block_app_hash. This addition supports the testing of the new protocol version functionality.

---

126-127: LGTM: Addition of protocol version properties in expectedScope

The new protocolVersion and desiredProtocolVersion properties in the tenderdash object of expectedScope correctly reflect the expected output of the status command. The values (3 and 4 respectively) match the mock data provided, ensuring proper testing of the new functionality.

---

150-152: LGTM: Addition of third mockFetch call for ABCI info

The modification to mockFetch to include a third call that resolves with mockAbciInfo is appropriate. This change correctly mocks the new API call for retrieving ABCI info, following the established pattern for other API calls in the test.

---

176-180: LGTM: Consistent addition of protocol_version object

The addition of the protocol_version object in the "platform syncing" test case maintains consistency with the previous test case. This ensures that protocol version information is available and tested even when the platform is in a syncing state.

---

195-203: LGTM: Consistent addition of mockAbciInfo object

The addition of the mockAbciInfo object in the "platform syncing" test case is consistent with the previous test case. This ensures that ABCI info is available and tested even when the platform is in a syncing state, maintaining thorough test coverage.

---

220-221: LGTM: Consistent addition of protocol version properties across test cases

The protocolVersion and desiredProtocolVersion properties have been consistently added to the expectedScope object across various test scenarios. The values are appropriately set (specific values for success cases, null for error cases), reflecting the expected behavior in different situations. This consistency ensures comprehensive test coverage for the new protocol version functionality.

Also applies to: 277-278, 332-333, 391-392, 491-492, 549-550

---

Line range hint 1-571: Overall assessment: Well-implemented and thoroughly tested changes

The modifications to this test file comprehensively cover the addition of protocol version information to the platform status command. The changes are consistent across various test scenarios, including both success and error cases. The new mock objects and expected outputs are well-structured and align perfectly with the PR objective.

Key points:

1. Consistent addition of protocol_version to mockStatus
2. Introduction of mockAbciInfo for ABCI information
3. Consistent updates to expectedScope with protocolVersion and desiredProtocolVersion
4. Appropriate handling of error cases with null values

The changes follow existing patterns in the test file, maintaining code consistency and readability. Overall, these modifications provide robust test coverage for the new protocol version functionality.

packages/dashmate/src/status/scopes/platform.js (4)

55-56: Initialization of protocolVersion and desiredProtocolVersion

Adding protocolVersion and desiredProtocolVersion to the info object with initial null values maintains consistency with the existing properties.

---

258-259: Addition of protocolVersion and desiredProtocolVersion to scope

Including protocolVersion and desiredProtocolVersion in the scope.tenderdash object enhances the status output by providing protocol version details.

---

273-273: Include version property in Drive information

Adding the version property to the drive object enriches the output with Drive service version details, aiding in diagnostics and monitoring.

---

122-125: Ensure robust JSON parsing of abci_info response

When parsing the tenderdashAbciInfoResponse object, handle potential JSON parsing errors that may occur if the response is not in the expected format.

To verify, you can run the following script:

Replace <tenderdashHost> and <port> with the appropriate variables from your configuration.

[pshenmic]

Very nicely