utility.batchAll should't fire a lot of utility.ItemCompleted

[nazar-pc]

Conceptually utility.batchAll is a wrapper that makes sure one of two is true: all transactions succeeded or all rolled back.

With that in mind, having utility.ItemCompleted event for every single transaction in a batch seems wasteful.

Thoughts?

[xlc]

It is required to correctly associate events with calls.

[nazar-pc]

Well, many extrinsics will have their own events anyway, so I don't really understand why it is necessary.

[xlc]

Take this example:

batch([
	batch([ transfer(Alice, 100) ]),
	batch([ transfer(Alice, 100) ])
])

Now there is only 1 transfer event. Can you tell which transfer emit the event? (without knowing the implementation details of transfer)

Note that batch will always success even the inner transfer failed.

You should read the issue / PR that add the item completed event for more context.

[nazar-pc]

I'm talking specifically about batchAll, for which utility.BatchCompleted must be sufficient. I'm not sure why you keep bringing batch here. I did check #9462 and understand how it it useful for batch call, but batchAll by definition either succeeds in full or doesn't go through at all.

[xlc]

batchAll([
	batch([ transfer(Alice, 100) ]),
	batch([ transfer(Alice, 100) ])
])

Now there is only 1 transfer event. Can you tell which transfer emit the event? (without knowing the implementation details of transfer)

[nazar-pc]

There are still events from batch call, so you can check if there is BatchInterrupted and if so which batch it corresponds to.

Since batch succeeds either way, I don't see how the fact that batchAll emits ItemCompleted is helpful here at all. We essentially have 4 ItemCompleted here instead of 2 and that serves literally no purpose unless I'm missing something obvious.