Transaction listing for an account in CloseTo address but not in From or To fields

I am running a node with Archival and Indexing turned on.
When I query it for transaction lists I get all transactions where the account appears in the From or To fields but not the CloseTo fields.

Is there anyway to get a listing of transactions where an account address does not appear in the From or To fields but only in the Close fields?

For example given a payment transaction:
pmt: 1 ALGO
from: Alice
to: Bob
close: Charlie

I need to call the REST API as:
/v1/account/Alice/transactions
OR
/v1/account/Bob/transactions

to see TransactionList that includes this transaction.
/v1/account/Charlie/transactions
however will not list it.

Incidentally - using AlgoExplorer shows all transactions for an address including those where it appears only in the CloseTo field.

Thanks.

The issue is the default endpoint behavior with Archival and Indexer on is to NOT include the close-to transactions. However there is a fall through ability, if you use the firstRound/lastRound parameters it’ll skip the archival/indexer code and bring back the close-to transactions. The below is part of some investigation into the endpoint I did earlier this year.

In fact, if the firstRound or lastRound parameters are set, the indexer check and functionality is skipped in favor of calling Node.ListTxns directly with the full set of rounds between firstRound and lastRound. There are no round limits on the parameters, allowing a full ledger search to be run without the indexer. This is also likely unintended behavior.

Interestingly it is this very use of the Node.ListTxns function, with all the rounds between fR/lR, that allows the return of transactions where the address searched is only present on the close field. This almost seems accidental, since there are no comments mentioning support for this use case.

Note, these are also shown in the https://goalseeker.purestake.io website.

It seems like a nasty oversight (bug) in the indexer to not include CloseTo as an indexed item.

@Tim - Thanks that did the trick. Indeed any call with the firstRound parameter being set (to anything but zero) generates all the transactions that include closeTo.

@aojjazz - agreed with you this is an oversight/bug or minimally needs a flag like “includeClose”