Skip to main content

fix-polygon-null-blockNumber

🐛 Bug Fixes​

Polygon pending transactions incorrectly marked as confirmed​

Goal: Prevent Polygon transactions still pending on-chain from being marked as confirmed in the database, which caused proof records to appear valid while their transaction was never mined.

Solution: Add an explicit tx.blockNumber null check in PolygonService#verifyTransaction before calling getBlock(). Previously, getBlock(null) returned the latest block, and latestBlock - null + 1 coerced null to 0 in JavaScript arithmetic, producing a confirmations count larger than minConfirmations and bypassing the guard entirely.

Files Modified:

  • src/services/polygon/polygon.service.ts - Guard tx.blockNumber before getBlock() and confirmation arithmetic

Polygon transactions dropped from mempool now marked as failed​

Goal: Proofs whose Polygon transaction was permanently dropped from the mempool (not found on-chain) were left in pending forever, causing an infinite retry loop.

Solution: Introduce TransactionDroppedError thrown when provider.getTransaction() returns null. verifyProofs() now returns { verified, failed } and the caller marks failed proofs with status: 'failed' via the new generic DatabaseService.failProofs<PS>(). The WithStatus type is extended with 'failed'. OTS and Chainpoint can reuse failProofs() without any additional database changes.

Files Modified:

  • src/services/polygon/polygon.service.ts - TransactionDroppedError class, updated verifyProofs() return type
  • src/database/database.service.ts - Generic failProofs<PS extends ProofSystem>() method
  • src/database/database.types.ts - WithStatus extended with 'failed'
  • src/app.service.ts - Destructure { verified, failed } from verifyProofs(), call failProofs() for dropped TXs