Skip to content

feat: Adding tx hash in response if required#91

Open
NicoMolinaOZ wants to merge 2 commits intomainfrom
return-back-tx-hash
Open

feat: Adding tx hash in response if required#91
NicoMolinaOZ wants to merge 2 commits intomainfrom
return-back-tx-hash

Conversation

@NicoMolinaOZ
Copy link
Contributor

@NicoMolinaOZ NicoMolinaOZ commented Feb 27, 2026

  • Adding tx hash in response if required

Summary by CodeRabbit

  • New Features
    • Added optional returnTxHash parameter to request transaction hashes be returned with API responses.
    • When enabled, on-chain transaction failures now return structured error details (reason, result code, reference link) instead of throwing errors, providing more actionable failure information.

@coderabbitai
Copy link

coderabbitai bot commented Feb 27, 2026

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Walkthrough

The PR introduces an optional returnTxHash flag enabling callers to request transaction hashes be returned on timeout or on-chain failure. The flag threads through type definitions, handler context, validation, and submission logic, replacing error-throwing with structured response returns when enabled.

Changes

Cohort / File(s) Summary
Type Definitions
src/client/types.ts, src/plugin/types.ts
Added optional returnTxHash?: boolean to request types (ChannelsXdrRequest, ChannelsFuncAuthRequest, ChannelAccountsRequest) and extended response types with optional error object containing reason, resultCode, and labUrl.
Request Handling & Validation
src/plugin/handler.ts, src/plugin/validation.ts
Threaded returnTxHash flag through PipelineContext and SubmitContext; extended validation to permit returnTxHash parameter alongside xdr/func-auth; propagated flag to per-request channel context for downstream access.
Submission Logic
src/plugin/submit.ts
Modified submitWithFeeBumpAndWait to return structured results with hash and error details instead of throwing when returnTxHash is true; added lock-extension logic for pending status and error-detail handling for on-chain failures.
Tests
test/handler.sequence-cache.test.ts, test/validation.test.ts
Added test suite validating returnTxHash flow behavior (pending/failed/confirmed statuses, lock/sequence handling, error details); updated validation tests to verify flag propagation and default values.

Sequence Diagram

sequenceDiagram
    participant Caller
    participant Handler
    participant Validation
    participant Submit
    participant Blockchain

    Caller->>Handler: Request {returnTxHash: true}
    Handler->>Validation: validateAndParseRequest
    Validation-->>Handler: ChannelAccountsRequest {returnTxHash: true}
    Handler->>Submit: submitWithFeeBumpAndWait {returnTxHash: true}
    
    alt On-Chain Failure
        Submit->>Blockchain: Submit transaction
        Blockchain-->>Submit: Failure response
        Submit-->>Handler: {status: 'failed', hash, error: {reason, resultCode, labUrl}}
    else Timeout
        Submit->>Blockchain: Submit & await response
        Blockchain-->>Submit: Timeout
        Submit-->>Handler: {status: 'pending', hash, transactionId}
    else Success
        Submit->>Blockchain: Submit & await confirmation
        Blockchain-->>Submit: Confirmed
        Submit-->>Handler: {status: 'confirmed', hash, transactionId}
    end
    
    Handler-->>Caller: ChannelsTransactionResponse with result/error
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

Suggested reviewers

  • tirumerla
  • zeljkoX
  • dylankilkenny

Poem

🐰 A flag hops through the code so true,
returnTxHash, a gift for you!
No more thrown errors in the night,
Just structured results, returned outright.
Hash and reason, bundled with care,
The rabbit's work beyond compare! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 16.67% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the main change: adding transaction hash to responses when requested via a new returnTxHash flag.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch return-back-tx-hash

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.


Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
src/plugin/handler.ts (1)

204-210: Consider clarifying the log message.

The log message says "Extending lock for WAIT_TIMEOUT error" but this code path handles a successful pending response (not an error/exception). Consider updating the message to reflect that this is the non-throwing pending path.

📝 Suggested log message fix
       if (ctx.returnTxHash && result.status === 'pending' && poolLock) {
-        console.log(`[channels] Extending lock for WAIT_TIMEOUT error`);
+        console.log(`[channels] Extending lock for pending transaction (returnTxHash enabled)`);
         await ctx.pool.extendLock(poolLock);
         poolLock = undefined; // skip release in finally
       }
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/plugin/handler.ts` around lines 204 - 210, The current console.log
message "[channels] Extending lock for WAIT_TIMEOUT error" is misleading because
this branch handles a non-throwing pending response; update the log in the block
that checks ctx.returnTxHash && result.status === 'pending' && poolLock to
clearly state it's extending the lock for the converted pending (non-error) path
— e.g., mention "pending response" or "converted WAIT_TIMEOUT to pending" — so
anyone reading logs knows this is the non-exception flow before calling
ctx.pool.extendLock(poolLock) and setting poolLock = undefined.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/plugin/handler.ts`:
- Around line 204-210: The current console.log message "[channels] Extending
lock for WAIT_TIMEOUT error" is misleading because this branch handles a
non-throwing pending response; update the log in the block that checks
ctx.returnTxHash && result.status === 'pending' && poolLock to clearly state
it's extending the lock for the converted pending (non-error) path — e.g.,
mention "pending response" or "converted WAIT_TIMEOUT to pending" — so anyone
reading logs knows this is the non-exception flow before calling
ctx.pool.extendLock(poolLock) and setting poolLock = undefined.

ℹ️ Review info

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 33a806c and eea5169.

📒 Files selected for processing (7)
  • src/client/types.ts
  • src/plugin/handler.ts
  • src/plugin/submit.ts
  • src/plugin/types.ts
  • src/plugin/validation.ts
  • test/handler.sequence-cache.test.ts
  • test/validation.test.ts

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

Successfully merging this pull request may close these issues.

3 participants