feat(api): Return after error in hasTx handler

[arepala-uml]

1. Added return statement in hashTx handler function whenever it receives an error.

Closes #377

Summary by CodeRabbit

• Chores
  • Improved internal error handling and control flow.

[coderabbitai]

Walkthrough

Removed error channel logic from handleHasTx and added early return statements after error handling. This prevents the function from continuing execution after logging error responses.

Changes

Cohort / File(s)	Summary
Error handling refactor in hasTx handler internal/api/api.go	Removed errorChan creation and ouroboros.WithErrorChan(errorChan) usage; eliminated error-awaiting goroutine; added early return after error logging during HasTx lookup failure

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Single function modified with localized changes
• Error channel removal is straightforward elimination of async error handling pattern
• Early returns are standard control flow additions to prevent cascading errors

Pre-merge checks and finishing touches

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The pull request title "feat(api): Return after error in hasTx handler" is concise and clearly describes the main change. It directly aligns with the PR objective to add return statements in the hasTx handler after error responses are written, and it matches the functionality outlined in the linked issue #377. The title is specific enough to convey the primary purpose without unnecessary noise or vague language.
Linked Issues Check	✅ Passed	The code changes directly address the objectives outlined in linked issue #377. The PR identifies the problem in handleHasTx where error responses were written without returning, and implements the fix by adding an early return after logging and returning a 500 status when a failure occurs during HasTx lookup. The removal of the error channel pattern and its associated goroutine appears to be part of the refactoring necessary to enable the early return behavior and prevent subsequent errors from continuing execution.
Out of Scope Changes Check	✅ Passed	All changes appear to be in scope for the stated objectives. The modifications focus on error handling within the handleHasTx function, including removing the error channel pattern and adding the early return statement. These changes work cohesively to achieve the goal of preventing execution continuation after error responses. No exported function signatures were altered, and no unrelated changes are evident in the summary.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch hashTx_error_handler

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e608b9e and b8ef0f1.

📒 Files selected for processing (1)

• internal/api/api.go (1 hunks)

🔇 Additional comments (2)

internal/api/api.go (2)

260-265: LGTM! Critical bug fix correctly implemented.

The addition of the return statement at line 264 correctly prevents the function from continuing execution after logging the error and sending a 500 response. Without this return, the function would continue to lines 266-270, potentially attempting to send additional HTTP responses, which would cause errors.

All error paths in handleHasTx now properly return after handling errors, meeting the PR objective from issue #377.

---

234-265: Error channel removal is complete and correct.

The verification confirms that error channel logic was fully removed from handleHasTx: no WithErrorChan references remain, and the async error handler goroutine has been completely eliminated from that function. The remaining errorChan references on lines 312-314 and 342 are correctly scoped to handleSubmitTx, where async error handling is appropriate for the SubmitTx operation. The removal was clean with no orphaned references, and the design decision to eliminate async error handling from the synchronous HasTx operation is sound.

---

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

[agaffney]

This is a fix, not a feature. Please update the commit message and PR title to reflect that

Changing and merging live on a call