Magento2: Transaction Repository fails to sort collection

[rhoerr]

Preconditions

2.0.x, 2.1.x are affected by primary issue.
All versions 2.x are affected by secondary issue in note (as of 2.2.0RC2.3).
cf. https://github.com/magento/magento2/issues/4870#issuecomment-328962566

Steps to reproduce

1. Place order with multiple items with an online payment method supporting partial capturing
2. Invoice one item online.

3. Invoice the remaining items online.

   Expected result

4. Both invoices will be created successfully, with funds captured from the gateway.

   Actual result

5. The first invoice will be captured online successfully.

6. The second invoice will not display the 'Capture Online' option, only allowing offline fund capture.
   

   Technical details

I identified this issue with our Authorize.Net CIM payment method extension (as on the marketplace), which supports partial capturing. The problem is occurring because:

1. Magento\Sales\Model\Order\Payment\Transaction\Repository->getByTransactionType() defines sort orders ($transactionIdSort, $createdAtSort), but Magento\Sales\Model\Order\Payment\Transaction\Repository->getList() fails to apply them to the collection.
2. The unsorted collection loads all authorization transactions in the order they were created. The collection loads a query of (for example) SELECT main_table.* FROM sales_payment_transaction AS main_table WHERE (txn_type = 'authorization') AND (payment_id = '25').
3. getByTransactionType() calls current() on the items returned by getList(), which gets the first loaded transaction.
4. This first transaction is closed, because it was already invoiced.
5. Because the transaction is closed, Magento\Sales\Model\Order\Payment->canCapture() returns false.
6. Because canCapture() is false, the order cannot be invoiced online, despite a valid open authorization transaction.

The expected behavior is that getList() in #1 correctly applies the sort order, such that the highest transaction ID is checked, not the first.

NOTE: The corrected behavior is still not ideal. getByTransactionType() applies a sort order of transaction_id DESC, created_at DESC -- however, there is no guarantee that transaction_id will always increase over time for all gateways. Authorize.Net is one notable exception: as of Oct 2015 transaction IDs are no longer guaranteed sequential.

Ideally, canCapture() should be looking specifically for any open authorization transaction, not the first authorization it finds according to arbitrary sort criteria.

[magento-engcom-team]

@rhoerr thank you for your report.
Please use the issue reporting guidelines to report an issue. Please, edit issue description and include the preconditions, the steps required to reproduce, the actual result, and the expected result.
Please, add the following information:

• [x] Preconditions: Magento version

[rhoerr]

The sorting issue (as explained in tech details) affects all versions prior to 2.2.0. In 2.0 and 2.1, getList() applies filters from $searchCriteria but nothing more. In 2.2 collectionProcessor was added, which covers sort orders.

My note is still outstanding as of 2.2.0RC2 and applies to all versions 2.0.0-2.2.0:

NOTE: The corrected behavior is still not ideal. getByTransactionType() applies a sort order of transaction_id DESC, created_at DESC -- however, there is no guarantee that transaction_id will always increase over time for all gateways. Authorize.Net is one notable exception: as of Oct 2015
Oct 2015 transaction IDs are no longer guaranteed sequential.

Ideally, canCapture() should be looking specifically for any open authorization transaction, not the first authorization it finds according to arbitrary sort criteria.

[magento-engcom-team]

Hi @rhoerr

This ticket has been marked as "Triage Wanted" due to low user involvement over time. Over the next 2 weeks we are looking for additional community feedback to decide if it should be archived or not. More information on this is available on the GitHub wiki.

Thank you for collaboration.

[magento-engcom-team]

@rhoerr thank you for your report.

Unfortunately, we are archiving this ticket now as it did not get much attention from both Magento Community and Core developers for an extended period. This is done in an effort to create a quality, community-driven backlog which will allow us to allocate the required attention more easily.

You may learn more about this initiative following this link.

Please feel free to comment or reopen the ticket if you think it should be reviewed once more. Thank you for collaboration.