A Tenant can seem to be getting a DIFFERENT tenant's TAA acceptance

I think I’ve found an issue with TAA acceptance in the Multi-Tenant case where a tenant that has NOT accepted the TAA for a ledger can seem to get a response from their TAA endpoint that says they HAVE accepted the TAA.

And I think this might have something to do with in-memory ACA-Py rather than the database persistence or any actual ledger write.

I don’t think this is any Tenant UI display issue.

I can reproduce with 2 tenants (both using sovrin-testnet) in this case as below

**Step 1:** Log in with a Tenant that has not accepted TAA.


_Tenant 1_ (created Dec 1) **has not accepted** the TAA for sovrin test.

**Step 2:** Log in with a Tenant that has accepted the TAA


_Tenant 2_ HAS accepted the TAA, calls the /taa endpoint and gets that

**Step 3:** Go back to Tenant 1 and refresh (call the /taa endpoint again)


Now _Tenant 1_ thinks it’s accepted the TAA on the same date as Tenant 2!

Has an Oct 23 acceptance date even though the Tenant did not exist until Dec 1...

**Step 5:** Restart ACA-Py (only tested this on OCP, by killing pods, haven’t tried locally or anything)


Now Tenant 1 is back to knowing it has not accepted the TAA

*******

Confirmed it's not specific to Tenant UI, and is "pod related" in the multi-pod scenario in dev

Using one Tenant's token in a single swagger instance I get 2 different TAA results randomly while it bounces between pods



Start by reproducing the issue through the /taa endpoint with two tenants across multiple pods, then compare the results before and after restarting ACA-Py. Trace how ACA-Py handles TAA state in memory versus persistence; done means each tenant consistently receives its own acceptance status regardless of pod or restart.

Written by the indexing model from the issue text.