Closed dalechyn closed 7 months ago
The latest updates on your projects. Learn more about Vercel for Git ↗︎
Name | Status | Preview | Comments | Updated (UTC) |
---|---|---|---|---|
frog | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Apr 3, 2024 6:50pm |
frog-frame | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | Apr 3, 2024 6:50pm |
@dalechyn is attempting to deploy a commit to the wevm Team on Vercel.
A member of the Team first needs to authorize it.
This also needs a test in Warpcast but it crashes today due to some internal server errors.
This also needs a test in Warpcast but it crashes today due to some internal server errors.
https://warpcast.com/dalechyn.eth/0xf0ae1ed7
tested, works as expected
This PR is a result of a research on why the frames with
Cache-Control: max-age=0
are not refreshing.First of all, the passed
Cache-Control
header must be lowercased. What happens is that@vercel/og
is setting a lowercasedcache-control
header key to"public, immutable, no-transform, max-age=31536000"
, yethono-og
setsCache-Control
(different case) to"public, immutable, no-transform, max-age=31536000"
(same value as prev one). Even if a user doesn't pass anyheaders
inimageOptions
, what ends up being under the hood there – is an object with bothcache-control
andCache-Control
headers set, and it looks like that the lowercased header takes a precedence over the uppercased one, since it started working correctly without patches when I've passed a lowercased header key.Secondly, WC caches the initial image url and expects you to update it under the same URL. However, since the
image
,imageOptions
andheaders
are serialized and passed inside search params, the initial/image?=image...
link will always change if the image is changing. So I've decided to add an internalfrog:image
(maybe change tofrog:initial_image
?) meta tag that stores the full link to the image with search params. This allows to serve the image for initial frame request under/image
route without any search params whatsoever by fetching the original frame, retrievingfrog:image
and redirecting user to it. It's not ideal – as it adds up an additional request for image retrieval (breaks idempotency), uneffectively re-rendering the frame twice: first time when the frame is accessed (i.e./
), and then to retrievefrog:image
from the image route (i.e./image
), which could cause some slow frames to time out. I cannot figure another way to persist the image state yet. However it doesn't seem as a huge problem as "usually" initial frames are resolved fast, as there is noframeData
to perform expensive operations with.As I write this long description, I think that what can be done though – is explicitly asking a user to opt out to a "refreshing" frame or not, warning him that the initial frame render will force it to render twice and setting
cache-control:max-age=0
in headers and performing this trick only if the flag is set.