@
0 reply
0 recast
0 reaction
Tony D’Addeo
@deodad
images don’t get cached, only proxied so we don’t expose users ips to 3parties even scrolling the feed most be something else related to the proxy like missing content type header that may be trivial to fix happy to look into it
0 reply
0 recast
0 reaction
@
0 reply
0 recast
0 reaction
Tony D’Addeo
@deodad
thanks for sharing, the URL that frame embed was pointing to is now a 404 https://fartcaster-action.vercel.app/api/image&s=724507676c1e1d0d8f0e14b0e8021672b2b9b4e76b7569cfd8ce0e5d58cf5556 it probably works on recaster because recaster didn't scrape the frame until a later point if you re-cast this frame on WC it will work fine since the current image defined in the metatag is valid once a cast is made we don't rescrape the metatags as there's not an obvious scalable way—at what point do you re-scrape the embed URL for any particular cast? a nice devtool I've considered adding for devs is a quick way to manually trigger a rescrapping of the metadata for a cast though the limitation is this only let's you fix a specific cast which might not be useful if there are hundreds
1 reply
0 recast
0 reaction
Tony D’Addeo
@deodad
stepping back the core problem is a framework generated a URL that then at somepoint (probably an upgrade that changed how rendered happened) became 404 which is unfortunate but not shocking given it was a very early version I think the idea that once you cast something the content of it doesn't change is reasonable and there's not an obvious problem with how Warpcast is caching anything
1 reply
0 recast
0 reaction
