SEP-6 deposit stuck in `pending_customer_info_update` after customer `ACCEPTED` on testanchor

[ElliotFriend]

This may be a follow-up to #1444 and/or #1445, which updated NotifyCustomerInfoUpdated to re-evaluate a pending_customer_info_update transaction from the customer's SEP-12 status. As of today, a SEP-6 deposit against testanchor.stellar.org still never advances out of pending_customer_info_update after the customer is fully ACCEPTED.

What version are you using?

The SDF-hosted reference implementation at testanchor.stellar.org (I don't know the exact Anchor Platform version, but I'd love to confirm the version). Flagging it because #1445 is supposed to cover exactly this case, so if testanchor is on a post-#1445 build, the fix doesn't appear to be taking effect for SEP-6 deposits.

What did you do?

A standard SEP-6 deposit for SRT:

1. SEP-10 auth; followed by PUT /sep12/customer with the base fields -> customer ACCEPTED.
2. Request GET /sep6/deposit?asset_code=SRT&funding_method=bank_account&amount=10&account=G... -> Response: { "id": "<txid>" }.
3. Poll GET /sep6/transaction?id=<txid> -> Response status: pending_customer_info_update.
4. Request GET /sep12/customer?account=G...&transaction_id=<txid> -> Response status: NEEDS_INFO, with the deposit-scoped required fields address, birth_date, id_country_code, id_issue_date, id_expiration_date, id_number.
5. Request PUT /sep12/customer with transaction_id=<txid> and all of those fields -> Response status: 202.
6. Request GET /sep12/customer?account=G...&transaction_id=<txid> -> Response status: ACCEPTED (every provided/required field ACCEPTED).
7. Continue polling GET /sep6/transaction?id=<txid>.

Also reproduced with the Demo Wallet (same transaction_id-scoped GET/PUT /sep12/customer sequence), so it doesn't look like it's specific to my own client. I can attach logs from both runs, if that helps.

What happened?

The transaction stays in pending_customer_info_update indefinitely. Its updated_at never changes after it is initiated, despite the customer being ACCEPTED for that transaction_id. Repeated GET /sep12/customer?transaction_id=<txid> requests keep returning ACCEPTED, but the transaction is never re-evaluated. The only escape is to cancel, or to start a brand-new deposit. A fresh deposit from the same account (KYC already complete) goes straight to pending_anchor -> completed, confirming the KYC data is valid and that only the original transaction is orphaned.

What did you expect to see instead?

Once the customer's required info is submitted and accepted (with transaction_id), the customer-updated event should trigger notify_customer_info_updated, re-evaluate the parked transaction, and advance it to pending_user_transfer_start. So the original deposit <txid> should leave pending_customer_info_update on its own, without the user creating a new transaction.

If I'm misunderstanding the expected flow, or missing a step somewhere, I'm more than happy to adjust. Thanks!

[amandagonsalves]

@ElliotFriend thanks for the steps, and for ruling out a client-side issue by testing against the demo wallet too.

confirmed the bug.

for context: the internal check that's supposed to notice your kyc update and push the transaction forward is silently failing every time (reproduced live). the failure gets logged and dropped instead of retried, so the transaction never advances. same check is used on sep31, so likely affected too, though not yet reproduced there. sep24 is fine, but only because it has no equivalent auto-check at all.

will update here once the fix ships.