[bug]: `SyncUniverse` seems to return too early

[ZZiigguurraatt]

Here is my situation

1. Alice has some assets she wants to send to Oliver.
2. Oliver creates a taproot asset address and gives it to Alice
3. Alice sends the assets using SendAsset
4. 10 blocks are mined
5. Alice and Oliver both wait until tapd is sync_to_chain.
6. Oliver runs SyncUniverse with sync_mode=0 and then sync_mode=1 to get updated proofs from Alice.
7. Oliver runs ListAssets, but he doesn't see the assets yet.
8. Oliver keeps running ListAssets for a few seconds until he finally sees the assets.
9. Alice creates a taproot asset address and gives it to Oliver
10. Oliver tries to send the assets back using SendAsset but he gets ERROR MESSAGE: unable to fund address send: error funding packet: unable to list eligible coins: unable to query commitments: mismatch of managed utxo and constructed tap commitment root.
11. Oliver keeps trying to send again for another few seconds and eventually the send works.

I see two possible (either one or both) causes of the outcome in step 7 (and maybe step 10):

1. Maybe sync_to_chain (https://github.com/lightninglabs/taproot-assets/blob/88bb9401d604bd5068770c23e66a8512a38c7aa2/taprpc/taprootassets.proto#L1611-L1614) is true before Alice actually finishes creating the updated proofs after blocks are mined, so when Oliver tries to run SyncUniverse he isn't actually getting the updated proofs yet. If that is the case, I think we need sync_to_chain to not return true until after all things (like proof generation) related to new blocks are complete. I don't think this is the case though because SyncUniverse is not re-run in step 8.
2. SyncUniverse returns after the data is transferred but before the proofs are validated and added to tapd's state machine(?).

Here is another clue: The more transfers I've made back and forth between Alice and Oliver, the more time after step 6 until Oliver can successfully see the assets with ListAssets and send with SendAsset.

If this is a bug you'd like to prioritize I can try to create an itest for it.

[ZZiigguurraatt]

Here is another clue: The more transfers I've made back and forth between Alice and Oliver, the more time after step 6 until Oliver can successfully see the assets with ListAssets and send with SendAsset.

Actually, more testing may be required to validate this statement.

[Roasbeef]

Oliver runs SyncUniverse with sync_mode=0 and then sync_mode=1 to get updated proofs from Alice.

Oliver doesn't need to do that. He made the address, therefore once things are confirmed on chain, he'll detect that, then reach out to the universe server to obtain the proofs.

[Roasbeef]

If you can write an itest to demonstrate this issue, leaving out that manual sync or with it, then that's valuable based on the error you seem to get at times.

cc @GeorgeTsagk is this somethign we've ran into w/ the loadtests if it's a matter of enough times back n forth?

[ZZiigguurraatt]

Oliver runs SyncUniverse with sync_mode=0 and then sync_mode=1 to get updated proofs from Alice.

Oliver doesn't need to do that. He made the address, therefore once things are confirmed on chain, he'll detect that, then reach out to the universe server to obtain the proofs.

OK, so I was unaware that Oliver could detect a receive to his address on chain without fetching proofs first.

So, does this mean that https://github.com/lightninglabs/taproot-assets/issues/1720 and https://github.com/lightninglabs/taproot-assets/issues/1731 are really only relevant to issuance proofs and not transfers?

[Roasbeef]

So, does this mean that https://github.com/lightninglabs/taproot-assets/issues/1720 and https://github.com/lightninglabs/taproot-assets/issues/1731 are really only relevant to issuance proofs and not transfers?

Yeah. If you're expecting a transfer, then as soon as the transaction creating it hits the chain, we'll start to access the universe server. Issuance events on the other hand may just happen unbeknownst to you, so we just sync them in the background as they happen.

[ZZiigguurraatt]

FYI: bullet point number 2 in https://github.com/lightninglabs/taproot-assets/pull/1741#issue-3330920165 mentions the same error message, but I can confirm that https://github.com/lightninglabs/taproot-assets/pull/1741 did not fix this issue.