Transaction event count differs to length of list of returned events

[friedger]

Describe the bug
The api returns a higher number of events than it actually can deliver

To Reproduce
Steps to reproduce the behavior:

1. Fetch https://api.hiro.so/extended/v1/tx/0xd45e090ac442380cf50655e3d1c904c355a501d6dffa3b5e4799083062469dbc
2. See event count 24 and event[10] has index 19
3. Fetch https://api.hiro.so/extended/v1/tx/0xd45e090ac442380cf50655e3d1c904c355a501d6dffa3b5e4799083062469dbc?event_offset=12
4. See event count 24 and event[0] has index 13 and event[5] has index 24
5. The total list of events delivered by the api is 13 different events (11 from first call + 2 new event from second call)

Expected behavior
All events with index 0 to 23 can be retrieved.

[zone117x]

This appears to be caused by a quirk/bug in how pox events are indexed. The pox events are sent as regular smart_contract_log print type events, so initially they are marked for insertion as a regular print type event. Then they are detected as special pox events and also marked for insertion as a special pox type event.

The result is that each pox event takes up two event index slots.

stacks-blockchain-api/src/event-stream/event-server.ts

Lines 719 to 736 in 3f5408f

	for (const tx of dbData) {
	const sortedEvents = [
	tx.contractLogEvents,
	tx.ftEvents,
	tx.nftEvents,
	tx.stxEvents,
	tx.stxLockEvents,
	tx.pox2Events,
	tx.pox3Events,
	tx.pox4Events,
	]
	.flat()
	.sort((a, b) => a.event_index - b.event_index);
	tx.tx.event_count = sortedEvents.length;
	for (let i = 0; i < sortedEvents.length; i++) {
	sortedEvents[i].event_index = i;
	}
	}

So luckily there aren't any events actually missing from that endpoint. There are only a total of 12 events for that tx, even though there appears to be more because of the index duplication bug.

It's relatively easy to fix this for new blocks that come in, but difficult to implement a fix to de-duplicate/re-index past events.