feat(sdk): return state transition execution error

[shumkov]

Issue being fixed or feature implemented

The wait_for_response method didn't handle wait for state transition response with execution error. It led to the "metadata is missing" instead of actual state transition execution error.

What was done?

• return serialized consensus error instead of cbored metadat from DAPI
• handle error result and deserialize consensus error
• return StateTransitionBroadcastError with all details in case if state transition execution failed

How Has This Been Tested?

With existing tests and DET

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

  • Improved error reporting during state transition broadcasts, offering clearer, more structured feedback.
  • Enhanced extraction and presentation of specific consensus error details to provide users with precise information when issues occur.
  • Introduced a new error type for state transition broadcasts to improve error granularity.

• Bug Fixes

  • Enhanced error handling in various components to ensure accurate reporting and processing of state transition errors based on response versions.
  • Updated error handling logic to ensure metadata is only set when error data is present.

[coderabbitai]

Warning

Rate limit exceeded

@shumkov has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 16 minutes and 12 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between 0669d3c and a573c60.

📒 Files selected for processing (1)

• packages/js-dapi-client/test/unit/methods/platform/waitForStateTransitionResult/waitForStateTransitionResultFactory.spec.js (2 hunks)

Walkthrough

This pull request enhances error handling across multiple components. In the JavaScript modules, error metadata handling is refined by extracting consensus error data directly using the 'dash-serialized-consensus-error-bin' key. In the Rust SDK, a new error type—StateTransitionBroadcastError—has been introduced along with a conversion implementation from proto messages. Additionally, response processing in the Rust broadcast module now matches gRPC response versions to trigger specific error handling. These changes refine the structure and clarity of error reporting for state transition broadcasts.

Changes

File(s)	Change Summary
packages/dapi/.../waitForStateTransitionResultHandlerFactory.js packages/js-dash-sdk/.../broadcastStateTransition.ts	Updated error handling to extract consensus error metadata using the 'dash-serialized-consensus-error-bin' key, replacing generic CBOR encoding with direct extraction and assignment.
packages/rs-sdk/.../error.rs packages/rs-sdk/.../broadcast.rs	Introduced new error type StateTransitionBroadcastError with a TryFrom implementation for proto conversion and enhanced response version matching to trigger structured error handling in state transition broadcasts.
packages/dapi/test/integration/grpcServer/handlers/platform/waitForStateTransitionResultHandlerFactory.spec.js	Modified test setup to reflect new error metadata structure and improved error handling reliability with a try...finally block in tests.
packages/js-dapi-client/lib/methods/platform/waitForStateTransitionResult/ErrorResult.js packages/js-dapi-client/lib/methods/platform/waitForStateTransitionResult/WaitForStateTransitionResultResponse.js packages/js-dash-sdk/src/SDK/Client/Platform/IStateTransitionResult.ts	Updated type annotations for error handling, specifying `Buffer

Sequence Diagram(s)

sequenceDiagram
    participant Client as Client
    participant Handler as waitForStateTransitionResultHandler
    participant ErrorFn as createStateTransitionDeliverError
    Client->>Handler: Initiate state transition request
    Handler->>ErrorFn: Process gRPC error (txDeliverResult)
    ErrorFn->>ErrorFn: Check for 'dash-serialized-consensus-error-bin' in metadata
    ErrorFn->>Client: Return StateTransitionBroadcastError with error data

Loading

sequenceDiagram
    participant B as BroadcastStateTransition
    participant SDK as Rust SDK
    participant GRPC as gRPC Response
    B->>SDK: Invoke wait_for_response
    SDK->>SDK: Match grpc_response version (e.g., V0)
    SDK->>SDK: If error exists, convert response to StateTransitionBroadcastError
    SDK->>B: Return structured error

Loading

Possibly related PRs

• fix(sdk): failed to deserialize consensus error #2410: Modifies consensus error deserialization in the Error enum, which aligns with the enhanced error extraction in this PR.
• fix(dapi): invalid state transition failed with already in chain error #2270: Adjusts error handling in the broadcastStateTransition function and the structure of gRPC error metadata, closely relating to the changes presented here.
• refactor(sdk)!: separate dash core client error #2380: Introduces a new error type, DashCoreError, and updates error handling, which relates to the improvements made in this PR regarding state transition error management.

Suggested labels

js-sdk

Suggested reviewers

• QuantumExplorer

Poem

Oh, hopping through the code I go,
Fixing errors high and low.
With consensus keys in hand,
My changes now do grandly stand.
From bytes to bunnies, watch us grow!
🐇✨

---

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 generate docstrings to generate docstrings for this PR. (Beta)
• @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: 0

🧹 Nitpick comments (5)

packages/rs-sdk/src/platform/transition/broadcast.rs (1)

88-109: Ensure future response versions remain compatible
Matching on grpc_response.version is a good approach to catch newly introduced versions at compile-time. However, consider using a _ => None arm if you prefer a safe fallback for unrecognized versions in production. Otherwise, this strict match is fine for forcing explicitly handled future versions.

packages/js-dash-sdk/src/SDK/Client/Platform/broadcastStateTransition.ts (1)

92-94: Consider verifying or defaulting error.data
Assigning error.data to grpcError.metadata is straightforward. However, if error.data can be null or undefined, consider null-checking or providing a default to avoid potential runtime errors.

packages/dapi/lib/grpcServer/handlers/platform/waitForStateTransitionResultHandlerFactory.js (1)

52-56: Use a shared constant for the metadata key
Defining 'dash-serialized-consensus-error-bin' as a constant in a central module can help avoid typos and maintain consistency across the codebase.

packages/rs-sdk/src/error.rs (2)

87-97: Consider using an enum for the error code field.

Instead of using a raw u32 for the error code, consider creating an enum to represent the possible error codes. This would provide better type safety and self-documentation.

Example implementation:

#[derive(Debug, Clone, Copy)]
pub enum StateTransitionBroadcastErrorCode {
    InvalidFormat = 1,
    ValidationFailed = 2,
    // Add other specific error codes
}

pub struct StateTransitionBroadcastError {
    pub code: StateTransitionBroadcastErrorCode,
    pub message: String,
    pub cause: Option<ConsensusError>,
}

---

99-122: Use more idiomatic Rust for the length check.

The length check can be written more idiomatically using !is_empty().

-        let cause = if value.data.len() > 0 {
+        let cause = if !value.data.is_empty() {

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9daa195 and 52e0592.

📒 Files selected for processing (4)

• packages/dapi/lib/grpcServer/handlers/platform/waitForStateTransitionResultHandlerFactory.js (1 hunks)
• packages/js-dash-sdk/src/SDK/Client/Platform/broadcastStateTransition.ts (1 hunks)
• packages/rs-sdk/src/error.rs (2 hunks)
• packages/rs-sdk/src/platform/transition/broadcast.rs (2 hunks)

🧰 Additional context used

🧠 Learnings (1)

packages/dapi/lib/grpcServer/handlers/platform/waitForStateTransitionResultHandlerFactory.js (1)

Learnt from: shumkov
PR: dashpay/platform#2270
File: packages/dapi/lib/grpcServer/handlers/platform/broadcastStateTransitionHandlerFactory.js:90-96
Timestamp: 2024-11-12T14:56:12.334Z
Learning: In `broadcastStateTransitionHandlerFactory.js`, error handling when querying transaction status is handled in the API script.

⏰ Context from checks skipped due to timeout of 90000ms (7)

• GitHub Check: Rust packages (dash-sdk) / Tests
• GitHub Check: Rust packages (dash-sdk) / Linting
• GitHub Check: Rust packages (dash-sdk) / Check each feature
• GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
• GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
• GitHub Check: Build Docker images (DAPI, dapi, dapi) / Build DAPI image
• GitHub Check: Build JS packages / Build JS

🔇 Additional comments (3)

packages/rs-sdk/src/platform/transition/broadcast.rs (2)

3-3: No issues with the new import statement
This import aligns with the new error handling logic and appears consistent with the changes in this file.

---

7-10: Imports for handling gRPC response versions
These new imports cleanly separate versioned response handling (wait_for_state_transition_result_response_v0), improving maintainability and clarity by providing version-specific logic.

packages/rs-sdk/src/error.rs (1)

2-2: LGTM! Well-structured error handling implementation.

The new error variant and its transparent error propagation align well with Rust's error handling best practices.

Also applies to: 81-85

[pauldelucia]

LGTM after tests are fixed. Works in DET.