David Lutterkort

The timestamps were a red herring. What's happening is this: when a subgraph starts, we assume that the last time we did a rollup is the block time of the...

> Hello, I'm encountering the same error while indexing contracts on the Abstract Testnet with the subgraph (Deployment ID: `Qmd6J1vaLnKCtnfKEBpmzEUv7Ng1y73EDQiZTHyopj486H`, Slug: `noodles-subgraph-testnet`). Is there a workaround to resolve this issue?...

Sorry, I forgot to report here, but that issue has been fixed for a week or two now (again) It was caused by a rollback to an earlier version; the...

It's already possible to have multiple calls on the same event handler. Just give it different labels, and that works; something like ```yaml calls: totalsBasicLiquidator: Comet[event.address].totalsBasic(event.params.liquidator) totalsBasicBorrower: Comet[event.address].totalsBasic(event.params.borrower) ``` The...

This is really a graph-cli issue - it should already warn about the missing handler before the subgraph is deployed. THe most elegant way to address this would be through...

@domob1812 Sorrry for the long radio silence, just coming back to that: can you confirm that in your case the subgraph removes entities without first checking if they exist? That...

I just opened a PR that will fix this problem. Once that's out and deployed, you should be able to go back to using immutable entities as that will be...

Yes, ultimately we need to avoid storing large arrays because they interact very badly with how we handle versioning/time-travel by storing the entire entity for each version. There's two approaches...

> The complication with arrays is that they preserve insertion order, so we'd need to store the index of the entry and update those indexes when the array is mutated....

Rebased to latest master (and cleaned up a little)