feat: add vercel blobs to cache historical subgraph data #240
Conversation
Signed-off-by: Matt Rice <[email protected]>
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
vercel
bot
temporarily deployed
to
Preview – amoy-optimistic-oracle-dapp-v2
Signed-off-by: Matt Rice <[email protected]>
vercel
bot
temporarily deployed
to
Preview – amoy-optimistic-oracle-dapp-v2
vercel
bot
temporarily deployed
to
Preview – sepolia-optimistic-oracle-dapp-v2
Signed-off-by: Matt Rice <[email protected]>
vercel
bot
temporarily deployed
to
Preview – sepolia-optimistic-oracle-dapp-v2
vercel
bot
temporarily deployed
to
Preview – amoy-optimistic-oracle-dapp-v2
Signed-off-by: Matt Rice <[email protected]>
Signed-off-by: Matt Rice <[email protected]>
Signed-off-by: Matt Rice <[email protected]>
Signed-off-by: Matt Rice <[email protected]>
Signed-off-by: Matt Rice <[email protected]>
| const remainingRequests = await fetchAllRequests( | ||
| url, | ||
| queryName, | ||
| oracleType, | ||
| Number(requests[0].time), | ||
| ); | ||
| requests = [...remainingRequests, ...requests]; |
There was a problem hiding this comment.
So does this mean we're sorting from oldest to newest? Then we'd have some newest (< 12hrs old ) requests not stored in the blob, those will be fetched from the subgraph?
There was a problem hiding this comment.
Yep! Technically, everything is in descending order of timestamp and both are generated with the same code. The local one just has a single parameter difference that it filters for elements after the last timestamp in the blob.
|
|
||
| if (blobValue === null || isBlobExpired(blobValue)) { | ||
| // This forces the vercel function to update the blob in the background. | ||
| waitUntil(updateBlob(blobName, url, queryName, oracleType as OracleType)); |
There was a problem hiding this comment.
I didn't know waitUntil was available, that's great 👍
|
|
||
| const blobValue = await kv.get<BlobValue>(blobName); | ||
|
|
||
| if (blobValue === null || isBlobExpired(blobValue)) { |
There was a problem hiding this comment.
Does this mean that ALL requests are potentially stale by up to 12 hours? For example if request A has been proposed, in this cached data will still be marked as "Requested" for 12 hours until the cache is updated.
There was a problem hiding this comment.
No, so the blob will be out of date, but we augment the blob data with local data from the subgraph.
One thing I'm assuming is that the graph data doesn't change once its timestamp has passed (i.e. each element that we get from the graph effectively represents an event). So this is a good point. If that's not true, then this may allow for stale state if the timestamp isn't updated.
There was a problem hiding this comment.
These entities from the subgraph don't represent events per se, they are single PriceRequest object that get updated as they change in state (Requested, Proposed, Settled).
The time field is set once at request time when they are initially created.
There's also proposalTimestamp, added at proposal time. We can add another at settle time if we need to.
Would this help at all? 🤔
There was a problem hiding this comment.
Hmmmm, yeah, so this may be a problem.
No description provided.