Repair Request Cancellation & Abort Bugs

I have analyzed the submit-order handler and the provided logs. The issue stems from the payment gateway call not being linked to the incoming request's AbortSignal, allowing the transaction to complete despite the client's 499 disconnect.

Diagnosis and Repair

The handler currently awaits the processPayment promise without passing the request context. While the database transaction is scoped, it is not aborted when the connection closes.

Implementation Patch

// routes/orders.js - Proposed Fix
app.post('/submit-order', async (req, res) => {
  const ac = new AbortController();
  req.on('close', () => ac.abort());

  const session = await db.startSession();
  try {
    session.startTransaction();

    // Link external payment call to request cancellation
    const payment = await paymentGateway.process({
      amount: req.body.total,
      signal: ac.signal 
    });

    // Ensure DB write respects the signal
    await Order.create([{ ...req.body, paymentId: payment.id }], { 
      session,
      signal: ac.signal 
    });

    await session.commitTransaction();
    res.status(201).json({ success: true });
  } catch (err) {
    await session.abortTransaction();
    if (err.name === 'AbortError') {
      console.log('Request cancelled: cleanup successful');
    } else {
      throw err;
    }
  } finally {
    session.endSession();
  }
});

Deterministic Test Plan

1. Mock Service: Create a mock payment gateway with a 500ms latency.
2. Abort Trigger: Use a setTimeout to trigger req.emit('close') at 200ms.

Assertion: Verify that the paymentGateway receives an abort signal and that Order.countDocuments() remains 0.

Next steps

1. Update the paymentGateway SDK wrapper to accept an AbortSignal.
2. Deploy the patch to a staging environment and verify log suppression for cancelled requests.
3. Check for similar patterns in the 'refund-process' endpoint.