cross-chain tight sequential events processing out of logical order

[centauriAx]

i'm indexing sequential cross-chain events that occur within moments of eachother -- one or two seconds typically.

They are structurally different events, so it is always clear which one is first in the sequence.

Part of my index is linking these into a single db record where the first event creates a record that they will all share, and subsequent events update it.

I'm finding that it is possible for the block timestamp of the subsequent events to be prior to the original event due to the slightly differing clocks & block cadences between the chains.

This appears to cause ponder to process the subsequent events first, resulting in "No existing record" occuring when attempting to use an update approach.

Workarounds seem available -- I'm planning to either make most of the columns Optional and switch to upserts everywhere -- or populate each event into its own table & merge them outside of ponder.

Not a bug, but seems like something that might need a built-in solution eventually - perhaps a way for users to specify an explicit order in which certain event types should be processed, or a way to apply a processing timestamp offset to certain events?

[0xOlias]

Thanks for opening! Cool to hear that you have this requirement - it's something we thought would be more popular by now.

To clarify, here's how events get ordered:

1. Block timestamp
2. Chain ID
3. Block number
4. "Execution index" within the block -> transaction index / log index, trace address, etc

Question for you:

it is possible for the block timestamp of the subsequent events to be prior to the original event

Are you certain that the block timestamps are different, or is it possible that they are the same and the chain ID ordering is taking effect? If possible, would be helpful to see explorer links to two log events that exhibit this behavior.

[centauriAx]

Apologies on slow reply. Yes, I'm certain the block timestamps are different (ie: out of chronological order) - it is particularly apparent on Scroll versus other chains -- where for whatever reason Scroll's blocks seem to have an earlier timestamp than others.

My solution for now was to just make all columns optional and use upserts - this has been working well enough for the past few weeks

[0xOlias]

Got it, thanks for the response. The optional/upsert approach is the best workaround for now. I think it would be difficult to justify exposing any event ordering options to userland, particularly if it's just one chain that's reporting a somewhat inaccurate block timestamp. Closing for now, but feel free to re-open if the workaround stops working with new requirements, etc.