Why does the bitcoin client send transaction's txid and wtxid in 'inv' process?

Question

I'm reading the source code of Bitcoin Core, and I found that in the inv process, nodes will relay both txid and wtxid to other peer nodes. I have the following questions:

1. Why does the node send these two ids, what are the benefits?
2. Suppose a transaction's txid is A, and its wtxid is B. Nodes will relay A and B inv announcements to peers. After a client received A first, will the client mark this transaction "fAlreadyHave" when receiving B later?

Answer 1

Wtxid relay was introduced in BIP339, where you'll find more details on the rationale and design.

Whenever a node supports BIP339, it will advertize that to its peers, through the wtxidrelay negotiations message. When those peers support BIP339 as well, they may choose to advertize transactions through their wtxid instead of their txid.

Every transaction is only advertized once (using the txid for normal peers, and using the wtxid for BIP339 peers) on each connection. That's not the code you posted though; that code is for populating the relay pool: the set of recent transactions which is used to answer getdata requests sent in response to transactions advertized by invs. Because some peers may request using the txid, and some may requests using the wtxid (mostly matching their BIP339 support, but even BIP339 peers will in some cases request using txids), both are added to the relay pool.

1. Why the node send these two ids, what are the benefits?

Wtxid based relay is better, but is not available to pre-BIP339 peers, so both have to remain supported.

2. Suppose a transaction's txid is A, and its wtxid is B. Nodes will relay A and B inv to peers. After a client received A first, will the client mark this transaction "fAlreadyHave" when receiving B later?

Generally the same transaction is only advertized once per connection, but it is possible that a node hears a txid A first, and the wtxid B later from another peer. If the actual transaction was received already (by fetching tx using txid A), then both txid A and wtxid B will be considered "AlreadyHave".

Before the actual transaction is received, the node has no idea that advertisements for A and for B refer to the same transaction. To avoid duplicate requests, Bitcoin Core introduces a 2s delay before fetching transactions advertised using txids, to give wtxid peers a chance to advertize it first.