worker send logs asynchronously

[JukLee0ira]

Proposed changes

The pendingLogsFeed.Send(cpy) needs to be executed asynchronously.The Send operation happens while holding a lock. If other subsystems (like those subscribing to Log events) also try to acquire the lock in the Send() function, it could cause a deadlock, freezing the process. To fix this issue, we decided to revert the changes and return to a more reliable implementation.

Code History

In the changes made in #583 , pendingLogsFeed.Send() was moved out of the goroutine to reduce competition and make the code cleaner. The modified code was as follows:

if len(coalescedLogs) > 0 {
		cpy := make([]*types.Log, len(coalescedLogs))
		for i, l := range coalescedLogs {
			cpy[i] = new(types.Log)
			*cpy[i] = *l
		}
		pendingLogsFeed.Send(cpy)
	}
	if env.tcount > 0 {
		go func(tcount int) {
			err := mux.Post(core.PendingStateEvent{})
			if err != nil {
				log.Warn("[commitTransactions] Error when sending PendingStateEvent", "tcount", tcount)
			}
		}(env.tcount)

	}
}

However, in a later code review, it was found that this code has issues when run asynchronously because the lock remains held until copying is complete. If a subsystem subscribes to Log events while also waiting for the lock in the Send() function, this synchronization will freeze the process. Therefore, the implementation before PR 583 need to be reverted , as shown in the following code:

if len(coalescedLogs) > 0 || env.tcount > 0 {
		cpy := make([]*types.Log, len(coalescedLogs))
		for i, l := range coalescedLogs {
			cpy[i] = new(types.Log)
			*cpy[i] = *l
		}
		go func(logs []*types.Log, tcount int) {
			if len(logs) > 0 {
				pendingLogsFeed.Send(logs)
			}
			if tcount > 0 {
				err := mux.Post(core.PendingStateEvent{})
				if err != nil {
					log.Warn("[commitTransactions] Error when sending PendingStateEvent", "tcount", tcount)
				}
			}
		}(cpy, env.tcount)
	}

The reverted code has been tested and solves the stability issues caused by PR 583.

Reference PR
ethereum#16843

Types of changes

What types of changes does your code introduce to XDC network?
Put an ✅ in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)
• Regular KTLO or any of the maintaince work. e.g code style
• CICD Improvement
• N/A

Impacted Components

Which part of the codebase this PR will touch base on,

Put an ✅ in the boxes that apply

• Consensus
• Account
• Network
• Geth
• Smart Contract
• External components
• Not sure (Please specify below)

Checklist

Put an ✅ in the boxes once you have confirmed below actions (or provide reasons on not doing so) that

• This PR has sufficient test coverage (unit/integration test) OR I have provided reason in the PR description for not having test coverage
• Provide an end-to-end test plan in the PR description on how to manually test it on the devnet/testnet.
• Tested the backwards compatibility.
• Tested with XDC nodes running this version co-exist with those running the previous version.
• Relevant documentation has been updated as part of this PR
• N/A

[gzliudan]

Please explain in detail

[JukLee0ira]

Please explain in detail

details have been added