fix: send tx to chain stg

[pedroanastacio]

Description

• Merge main with staging
• Fix bug in staging: When a user canceled a transaction and created a transaction identical to the canceled one, generating a transaction with the same hash, there was an error in the API that did not send the transaction to the chain.

Summary

• Replaces console.* with logger.*
• Adds canceled status to the array of ignored statuses in the transaction search query by hash
• Adds order by to query to get the newest transaction with de provided hash
• Adds test to ensure that a canceled transaction does not interfere with the sending of another transaction with the same hash
• Updates fuels version

Checklist

• I reviewed my PR code before submitting
• I ensured that the implementation is working correctly and did not impact other parts of the app
• I mentioned the PR link in the task

[guimroque]

🔴 CRITICAL: Security vulnerability - unauthenticated endpoint

Problem:
The /send/:hash route was moved outside the authMiddleware, making it accessible without authentication. This allows anyone to trigger transaction sending to the blockchain.

Suggestion:
Move the route back inside the auth middleware:

router.use(authMiddleware);
// ... other authenticated routes
router.post('/send/:hash', handleResponse(send));

[guimroque]

🟡 IMPORTANT: Missing input validation

Problem:
The hash parameter is used directly in database queries without validation. This could lead to injection attacks or unexpected behavior.

Suggestion:
Add hash validation at the beginning of the method:

if (!hash || typeof hash !== 'string' || hash.length < 10) {
  throw new BadRequest({ type: ErrorTypes.InvalidInput, message: 'Invalid hash format' });
}

[pedroanastacio]

Great point about validation, but in this case:

1. TypeORM uses prepared statements, so SQL injection is not a risk
2. If it were invalid, the database would return null, and a NotFound error would be sent in the response

[guimroque]

🔵 SUGGESTION: Consider database performance

Problem:
The query uses ORDER BY createdAt DESC which might impact performance if there's no index on createdAt column, especially with multiple transactions having the same hash.

Suggestion:
Ensure there's a database index on (hash, createdAt) or consider limiting the query:

.orderBy('createdAt', 'DESC')
.limit(1)

[guimroque]

Code Review - Summary

What was done

• Fixed bug where canceled transactions with same hash interfered with new transactions
• Added CANCELED status to ignored statuses in transaction query
• Added order by createdAt DESC to get newest transaction with same hash
• Replaced console.* with logger.* for proper logging
• Added comprehensive test case for the bug scenario
• Updated fuels version from 0.99.0/0.101.1 to 0.101.3
• Moved /send/:hash route outside auth middleware

Positive Points

• Good bug fix addressing a real edge case scenario
• Comprehensive test coverage for the specific bug
• Proper logging implementation replacing console statements
• Clear commit message and PR description
• Follows conventional commit format
• Appropriate use of logger with structured data

Issues Found

• Route security issue: /send/:hash endpoint moved outside authentication
• Missing input validation on hash parameter
• Potential performance impact from ordering without index consideration

Total comments: 3 (1 critical, 1 important, 1 suggestion)

[guimroque]

LGTM! ✅

Previous issues have been fixed. Code approved.