fix(pubsub): fix defer call in for loop

[zchee]

SSIA. Avoid the defer function call in for loop.

[zchee]

/cc @hongalex

[zchee]

@hongalex gentle ping

[hongalex]

Apologies for missing this the first time around. Could you explain in more detail why this is necessary? Calling defer in a for loop can lead to issues with freeing memory, but in this case, I believe the behavior is correct and wrapping it in anonymous function makes it harder to read.

[zchee]

@hongalex Example playground is here: https://go.dev/play/p/tM6Gt11reCo

I thought you assumed deferAnonFunc behavior, but actually when calling defer within a for loop, added functions to the defer stack are called in reverse order. (deferForLoop behavior
If we want to keep the order of bmsgs (which I think we should), we should enclose it in an anonymous function.

[hongalex]

Yeah I definitely overlooked the order of when the message spans are ended when using defer. In my mind, it's not a super pressing bug since the events are batched anyway on the exporter so the timing is fairly tight, but it would be nice to get correct.

If that's the case, I would prefer iterating over bmsgs rather than allocating space for the function calls. wdyt?

t.publishMessageBundle(ctx, bmsgs)
if t.enableTracing {
	for i, m := range bmsgs {
		m.createSpan.End()
		m.createSpan.AddEvent(eventPublishEnd)
        }
}

[zchee]

@hongalex I agreed your opinion.

But just for confirm, you means calling AddEvent before End instead of?

t.publishMessageBundle(ctx, bmsgs)
if t.enableTracing {
	for _, m := range bmsgs {
		m.createSpan.AddEvent(eventPublishEnd)
		m.createSpan.End()
    }
}

---

Edit: changed and pushed. PTAL.

[hongalex]

But just for confirm, you means calling AddEvent before End instead of?

Sorry, no I didn't. I copy and pasted the order from the defer side (because the opposite order is correct) but in this case we should be calling AddEvent and then End.
Thanks!