I learned from this question that transactions will be reverted and rollback after chain reorganization. But after a transaction is reverted, will the sender needs to resend this transaction? Or this transaction will automatically go into transactions pool and wait to be included in a new block?
When it comes to smart contracts, how smart contracts deal with this kind of revert/rollback problems due to chain reorganization?
Partial answer...
When it comes to smart contracts, how smart contracts deal with this kind of revert/rollback problems due to chain reorganization?
The smart contract itself doesn't need to deal with anything: it will be as though the transaction never happened, and no state changes occurred.
What might need to be dealt with are any changes that happen off-chain in response to the transaction. e.g. If your website/front-end has taken an action, such as a redirect, in response to the transaction completing, but then that transaction gets invalidated, then you'll need to ensure the front-end changes are reverted.
To do this, most people wait for a certain number of confirmations* before taking any subsequent actions.
[*I think the generally accepted number is 6, but the following question and its answers would imply that ephemeral chain forks above length 2 are extremely unlikely, so 6 might be overkill: Distribution of chain-reorganization events? ]
