Skip to content

[nil.js] Simplified Transaction Status Reporting in niljs #620

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

Open
gitshreevatsa opened this issue Mar 21, 2025 · 5 comments
Open

[nil.js] Simplified Transaction Status Reporting in niljs #620

gitshreevatsa opened this issue Mar 21, 2025 · 5 comments

Comments

@gitshreevatsa
Copy link
Collaborator

Overview

Enhance niljs transaction methods to return both transaction hash and detailed status information without requiring developers to manually loop through nested JSON structures.

Background

Currently, when using methods like smartAccount.sendTransaction or smartAccount.deployContract, developers only receive a transaction hash. To determine transaction status and error information, they must call client.getTransactionReceipt, then manually loop through complex nested JSON structures to check for failure flags and extract error messages.

Feature Requirements

Improve transaction-related methods in niljs to:

  1. Return transaction hash along with parsed status information in a single response
  2. Automatically extract and surface error messages when transactions fail
  3. Eliminate the need for manual JSON traversal to determine transaction outcomes

Technical Implementation Steps

  1. Create a transaction result parser:

    • Implement logic to traverse transaction receipt JSON
    • Extract status flags and error messages from nested structures
    • Transform complex receipt data into developer-friendly format
  2. Enhance transaction method return objects:

    • Return both transaction hash and parsed status information
    • Include formatted error messages when transactions fail
    • Provide boolean success indicator for quick status checks
  3. Update interfaces:

    • Modify return types for all transaction methods
    • Ensure backward compatibility with existing code
    • Document new return object structure
  4. Implement error categorization:

    • Standardize error message formats
    • Group common error types for easier handling
    • Provide context-specific error information

Technical References

Acceptance Criteria

  • All transaction methods return an object containing:
    • Transaction hash
    • Success/failure status
    • Detailed error message when applicable
  • Developers no longer need to manually traverse nested JSON
  • Failed transactions have clear, actionable error messages
  • Existing code expecting only transaction hash continues to work
  • Changes follow consistent patterns across the library
@idea404
Copy link
Collaborator

idea404 commented Mar 21, 2025

This issue is related to #173

With the await pattern for sending transactions we can follow syntax closer aligned to major client libs:

const tx = await wallet.someOp(); // Sends the transaction
const receipt = await tx.wait();  // Waits for it to be mined

With tx failing to be assigned if someOp() fails as it should throw an error

@Otaiki1
Copy link

Otaiki1 commented Mar 21, 2025

Would love to tackle this!

@ikemHood
Copy link
Contributor

Hi,

I’m Ikem, and I’d love to take this on! I’m a Software developer with 3 years of experience and strong programming principles, and I’m also very skilled in typeScript for projects like nil.js.

I can improve the transaction methods to return the hash and clear status info. I’ll build a parser to pull out status and errors, update the methods to return simple, friendly results, and keep old code working.

Let me do this, I’ll make it clean and easy.

Thanks,

Ikem

@manassehO
Copy link
Contributor

I would love to work on this @gitshreevatsa, I would build upon my implementation on #173

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants