{"entries":[{"lastCommit":{"author":{"email":"jared@awarm.space","name":"Jared Pereira","when":"2024-05-27T18:55:31.000000+01:00"},"committer":{"email":"jared@awarm.space","name":"Jared Pereira","when":"2024-05-27T18:55:31.000000+01:00"},"hash":"aec54ab9dcd357d48140693fa322996a9f5653ad","message":"add basic image block handling\n","tree":"2c78469d15d83f7c32685a7221bf411c43005619"},"mode":"0100644","name":"browserClient.ts","size":283},{"lastCommit":{"author":{"email":"jared@awarm.space","name":"Jared Pereira","when":"2024-05-15T12:33:03.000000-04:00"},"committer":{"email":"jared@awarm.space","name":"Jared Pereira","when":"2024-05-15T12:33:03.000000-04:00"},"hash":"a805b34a3b8e448f972a8e0d7fbfbb2cbcbc59e0","message":"init\n","tree":"2d34c3b4d4923e2f3c5feefb982c9764b2c797c1"},"mode":"0100644","name":"config.toml","size":6587},{"lastCommit":{"author":{"email":"jared@awarm.space","name":"Jared Pereira","when":"2026-07-18T22:16:59.000000-07:00"},"committer":{"email":"noreply@github.com","name":"GitHub","when":"2026-07-19T01:16:59.000000-04:00"},"hash":"6ad09ee8daa82cffe9e06da89278230b66eaf9a9","message":"Prevent full-table scans in PostgREST queries with order+limit+embed (#361)\n\n* Fence the feed query plan against full documents scans\n\nThe optimized feed query selected from documents ordered by sort_date\nwith a limit while filtering through a documents_in_publications embed.\nPostgREST expresses that embed filter as a LATERAL join referencing\ndocuments.uri, which pins documents as the outer side of the plan: the\nonly way to satisfy the order + limit is to walk documents_sort_date_idx\nacross the entire table, probing the membership table for every document\nuntil 50 match. For a small or inactive publication that is a full scan\nof documents on every feed poll (reproduced locally: 200k synthetic\ndocuments, 431ms and loops=200005 on the join probe, with the limit\nnever short-circuiting because the publication's posts are the oldest).\n\nServe the feed from get_publication_feed_docs instead — the same fix the\ntag page uses for the identical trap (20260702000000): a MATERIALIZED\nCTE fences the plan to start from the publication's own membership rows\n(the documents_in_publications pkey), enable_seqscan off keeps the join\nas documents pkey probes, and only the 50 returned rows detoast their\ndata jsonb. Work is bounded by the publication's post count (0.1ms for\na 5-post publication, 33ms for a 10k-post one, same dataset).\n\nOrdering is sort_date DESC NULLS LAST, restoring the pre-optimization\nsemantics (null dates sorted as epoch 0, i.e. oldest): the replaced\nquery's sort_date.desc put null-dated documents first, which also made\nrow 0 — the Last-Modified source — a null date.\n\nSince the migration deploys separately from the code, a missing function\ndegrades to fetching the publication's rows membership-first (a shape\nthat cannot hit the trap) and sorting in JS, mirroring the tag page's\nfallback.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_01XtiQx6hT88QJjnaF36qszZ\n\n* Guard against the order+limit+embed-filter full-scan trap in CI\n\nThis repo has now shipped the same planner trap three times (tag page,\nprofile/reader feeds, publication feeds): ordering a table by its own\ncolumn with a limit while an !inner embed filters the rows. PostgREST\ncompiles the embed filter into a LATERAL join referencing the outer\ntable, which pins the join direction, so the only available plan walks\nthe order column's index across the entire table probing the embed per\nrow — a full scan whenever the filter is selective. Make the trap\nmechanically detectable instead of relying on review memory:\n\n- scripts/check-supabase-query-plans.mjs: a syntax-level check (TS\n compiler API) that flags .from() queries combining an !inner embed\n with a top-level .order() + .limit(), following chains split across\n variable reassignments (the feeds service style). Suppressed by a\n `plan-checked:` comment above .from() stating why the shape is safe;\n wired into the deploy workflow after tsc and exposed as\n `npm run check-query-plans`.\n- The sweep found two latent instances scanning documents on the feed\n service (bsky-follows and subscription skeleton feeds — selective\n follow/subscription filters in !inner embeds) and one scanning\n documents_in_publications in resolveDocumentFilter (all filters live\n in embeds, full membership walk on 404 probes). These are annotated\n as `plan-checked: KNOWN DEBT` describing the fix each needs (fenced\n functions like get_reader_feed) rather than silently suppressed.\n getNewFeed's discover query is the one genuinely safe hit — its\n newest-first walk is the intended access path because the filters\n exclude only a small minority of recent documents.\n- .claude/skills/supabase-query-plans: the full explanation — why the\n LATERAL shape is structural (no index or ANALYZE can fix it), the\n three safe query shapes, the fenced-RPC recipe with its costs, and\n how to verify a plan against skewed synthetic data — plus a CLAUDE.md\n pattern bullet pointing at it.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_01XtiQx6hT88QJjnaF36qszZ\n\n* Drop the generateFeed fallback path\n\nThe migration deploys with the same push, so serve the feed from\nget_publication_feed_docs unconditionally and let a query failure\nsurface as a retryable 500 like the publication lookup above it.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_01XtiQx6hT88QJjnaF36qszZ\n\n* Fold the query-plan guidance into the CI check\n\nThe check's header and error message carry the fix recipes and\nsuppression rules directly, so the separate skill doc is redundant.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_01XtiQx6hT88QJjnaF36qszZ\n\n---------\n\nCo-authored-by: Claude ","tree":"4b86c80f9e8d847834c5c6fff39f6f7c4bdf6cc6"},"mode":"0100644","name":"database.types.ts","size":67469},{"lastCommit":{"author":{"email":"jared@awarm.space","name":"Jared Pereira","when":"2026-07-18T12:33:41.000000-07:00"},"committer":{"email":"noreply@github.com","name":"GitHub","when":"2026-07-18T15:33:41.000000-04:00"},"hash":"b108a055fd1f8eb74b4e6a27b829d895cce97740","message":"Cut Supabase + Vercel spend without changing user-facing behavior (#355)\n\n* Suppress yjs realtime broadcasts when no other peer is subscribed\n\nA solo editor streams doc updates every 50ms and cursor awareness every\n80ms into an empty channel — every message billed by supabase, delivered\nto nobody. Solo sessions are the common case, so this was the bulk of\n~7.9M billed realtime messages/month.\n\nTrack channel membership via presence and drop doc-update/awareness\nbroadcasts while no other peer is present. Late joiners converge through\nreplicache exactly as they already did for updates sent before they\nsubscribed. Recently received broadcasts also count as peer presence so\npre-presence clients keep working across the deploy boundary.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_018MbcWeXrpeshUJLFDJKzek\n\n* Cut database and storage egress in the hot read paths\n\nUncached supabase egress ran 839GB/mo against 53GB cached. Three\ncontributors addressed here:\n\n- Replicache pulls return a full document snapshot every time, and every\n open tab polled one per minute. Stretch the idle poll to 5 minutes and\n pull explicitly when the poke channel resubscribes after a drop, so\n convergence still happens immediately after a missed-poke disconnect.\n Worst case for a poke lost on a live socket is now 5 minutes of\n staleness for a passive viewer instead of 1.\n- The bsky feed skeleton endpoints selected entire document rows\n (including full content jsonb, 25 at a time, on unbounded external\n traffic) to read only a post ref. Project just uri/sort_date/refs.\n- storage-js expects cacheControl in seconds; passing a full header\n string stored a malformed Cache-Control (max-age=public, ...) on every\n uploaded image, defeating CDN caching of user assets.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_018MbcWeXrpeshUJLFDJKzek\n\n* Resize images with sharp instead of Supabase image transforms\n\nSupabase bills $5 per 1,000 origin images transformed per month\n(19,275 last cycle). Replace all three transform pipelines with sharp,\nwhich the repo already uses for cover thumbs:\n\n- atproto_images: resize the cached PDS blob in-function rather than\n via storage.download({transform}); also drops the per-request list()\n existence probe and reuses fetched bytes instead of re-downloading.\n- link_previews: store the screenshot already downscaled to its 240x208\n display size and serve the object directly, transform-free.\n- next/image loader: point at a new /api/resized_images sharp proxy\n (originals come off the storage CDN; responses are edge-cached for a\n year) instead of the render/image endpoint.\n\nOutput dimensions and no-upscale behavior match imgproxy's; EXIF\norientation is applied explicitly via rotate().\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_018MbcWeXrpeshUJLFDJKzek\n\n* Serve image bytes from Supabase's CDN via redirect, not through Vercel\n\nThe Vercel invoice shows fast data transfer already ~500GB past the\nincluded 1TB, so every image byte streamed through these routes bills at\n$0.15/GB — worse than the Supabase egress the sharp rewrite was saving,\nand cover/doc images are pure byte volume. Store each resized variant\n(and the cached original) in storage once and 302 to its public URL:\nbytes then leave via Supabase's CDN as cached egress ($0.03/GB with free\nheadroom) and Vercel serves only a year-long-edge-cached redirect.\n\nensureOriginalCached also repairs legacy objects stored with the\nmalformed 'max-age=public, ...' Cache-Control by re-uploading them once\nwith a well-formed value, since redirecting to an uncacheable object\nwould forfeit the CDN saving. Streaming from the PDS remains the last\nresort when nothing could be cached.\n\nTradeoff: one extra redirect hop per image on a cold browser cache.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_018MbcWeXrpeshUJLFDJKzek\n\n* Cut Vercel Fluid compute burned on screenshots, favicons, and push logging\n\nFluid bills provisioned memory for full instance wall time, so the\nmulti-second remote-browser renders behind og-images were the main\nburn: every unfurl bot re-fetch after the 60s revalidate paid a fresh\nrender. OG cards are effectively immutable post-publish — raise\nrevalidate to a day and let the CDN serve them (stale by at most a day\nafter an edit). The share-card screenshot route had no caching at all;\nedge-cache it per url.\n\nAlso: the per-leaflet favicon was force-dynamic + no-cache, running two\nDB queries and a satori render on nearly every page load — cache it,\npicking up theme edits within the hour. Gate the per-push performance\nlog summary behind LOG_PUSH_PERFORMANCE. Stop runtime-cache writes for\narbitrary user-pasted URLs in resolveBlueskyPostUrl (near-zero hit\nrate, one billed cache write per paste).\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_018MbcWeXrpeshUJLFDJKzek\n\n* Reduce Vercel request volume and reader-page bundle weight\n\n- Serve the hot feed from a CDN-cacheable GET route. It's identical for\n every user and already 5 minutes stale from redis, but each reader's\n load paid an uncacheable POST invocation returning 50 full posts.\n Worst-case staleness goes from ~5 to ~10 minutes.\n- Widen replicache pushDelay 500ms -> 1s: halves push invocations during\n sustained typing. Live co-editing latency rides the yjs channel;\n replicache-only changes (e.g. block moves) reach collaborators ~0.5s\n later, and unsent mutations survive tab close in local storage.\n- Load the comment editor and bsky share composer on interaction instead\n of bundling them: both drag prosemirror into every public post page\n for readers who never comment or share.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_018MbcWeXrpeshUJLFDJKzek\n\n* Drop sub-1%-impact interventions\n\nRanking the branch's changes by predicted monthly savings, three fall\nunder 1% of the total (~$310/mo) because their frequency drivers are\nhuman actions, not machine traffic: quote-screenshot caching\n(share-modal opens), the push perf-log gate (sub-ms CPU per push), and\nthe no-store paste-URL resolution (a runtime-cache write per paste).\nRevert them to keep the diff to changes that pay for their risk.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_018MbcWeXrpeshUJLFDJKzek\n\n* Answer conditional feed requests with 304s\n\nThe rss route gets polled harder than any page on the site (156K\nrequests in the last transfer window), and transfer out is billed even\non CDN cache hits, so every poll paid for the same unchanged bytes.\nFeed readers nearly all send If-None-Match; derive an ETag from the\nbody — generateFeed already pins the updated stamp so an unchanged feed\nis byte-stable — and return an empty 304 on match.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_018MbcWeXrpeshUJLFDJKzek\n\n* Snap image-resize dimensions to a fixed width ladder (#358)\n\nThe resized_images and atproto_images routes accept caller-controlled\ndimensions, and every novel value mints a permanent stored variant on\ncache miss — an unauthenticated caller could mint ~2000 objects per\nimage (~4M per cid for w×h) just by walking the width space. Snap\nrequests to a 4-entry ladder shared from supabase/imageSizes.js so the\nkeyspace per image is bounded: 360/800 are the app's own\ncover-thumbnail widths, 1200 covers document-body images at retina\ndensity, 2000 is the existing cap. Snapping up (never rejecting) keeps\nURLs already living in edge and browser caches working across the\ndeploy, and off-ladder requests collapse onto the same stored objects\nbecause the snapped value keys both the sharp resize and the variant\npath. atproto_images height is snapped too rather than dropped, keeping\nold cached URLs valid while bounding the w×h grid.\n\nAlign the clients so real traffic is on-ladder before it reaches the\nedge cache: the next/image loader snaps in the browser, and\nimages.deviceSizes is set to the ladder (imageSizes emptied — its\nentries must sit below the smallest deviceSize and every icon-sized use\nalready collapses to 360 via the loader) so srcset candidates come out\nof the same four widths instead of Next's 16-entry default. The share\ncomposer's 1000px cover prefetch moves to the 1200 rung it would be\nsnapped to anyway.\n\n\nClaude-Session: https://claude.ai/code/session_01MQBgS6Lb1BrTgg2pu1Bfm4\n\nCo-authored-by: Claude \n\n---------\n\nCo-authored-by: Claude ","tree":"38933109e777b0b845a3dec50d079a863f2a12b1"},"mode":"0100644","name":"imageSizes.js","size":934},{"lastCommit":{"author":{"email":"jared@awarm.space","name":"Jared Pereira","when":"2026-07-18T22:16:59.000000-07:00"},"committer":{"email":"noreply@github.com","name":"GitHub","when":"2026-07-19T01:16:59.000000-04:00"},"hash":"6ad09ee8daa82cffe9e06da89278230b66eaf9a9","message":"Prevent full-table scans in PostgREST queries with order+limit+embed (#361)\n\n* Fence the feed query plan against full documents scans\n\nThe optimized feed query selected from documents ordered by sort_date\nwith a limit while filtering through a documents_in_publications embed.\nPostgREST expresses that embed filter as a LATERAL join referencing\ndocuments.uri, which pins documents as the outer side of the plan: the\nonly way to satisfy the order + limit is to walk documents_sort_date_idx\nacross the entire table, probing the membership table for every document\nuntil 50 match. For a small or inactive publication that is a full scan\nof documents on every feed poll (reproduced locally: 200k synthetic\ndocuments, 431ms and loops=200005 on the join probe, with the limit\nnever short-circuiting because the publication's posts are the oldest).\n\nServe the feed from get_publication_feed_docs instead — the same fix the\ntag page uses for the identical trap (20260702000000): a MATERIALIZED\nCTE fences the plan to start from the publication's own membership rows\n(the documents_in_publications pkey), enable_seqscan off keeps the join\nas documents pkey probes, and only the 50 returned rows detoast their\ndata jsonb. Work is bounded by the publication's post count (0.1ms for\na 5-post publication, 33ms for a 10k-post one, same dataset).\n\nOrdering is sort_date DESC NULLS LAST, restoring the pre-optimization\nsemantics (null dates sorted as epoch 0, i.e. oldest): the replaced\nquery's sort_date.desc put null-dated documents first, which also made\nrow 0 — the Last-Modified source — a null date.\n\nSince the migration deploys separately from the code, a missing function\ndegrades to fetching the publication's rows membership-first (a shape\nthat cannot hit the trap) and sorting in JS, mirroring the tag page's\nfallback.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_01XtiQx6hT88QJjnaF36qszZ\n\n* Guard against the order+limit+embed-filter full-scan trap in CI\n\nThis repo has now shipped the same planner trap three times (tag page,\nprofile/reader feeds, publication feeds): ordering a table by its own\ncolumn with a limit while an !inner embed filters the rows. PostgREST\ncompiles the embed filter into a LATERAL join referencing the outer\ntable, which pins the join direction, so the only available plan walks\nthe order column's index across the entire table probing the embed per\nrow — a full scan whenever the filter is selective. Make the trap\nmechanically detectable instead of relying on review memory:\n\n- scripts/check-supabase-query-plans.mjs: a syntax-level check (TS\n compiler API) that flags .from() queries combining an !inner embed\n with a top-level .order() + .limit(), following chains split across\n variable reassignments (the feeds service style). Suppressed by a\n `plan-checked:` comment above .from() stating why the shape is safe;\n wired into the deploy workflow after tsc and exposed as\n `npm run check-query-plans`.\n- The sweep found two latent instances scanning documents on the feed\n service (bsky-follows and subscription skeleton feeds — selective\n follow/subscription filters in !inner embeds) and one scanning\n documents_in_publications in resolveDocumentFilter (all filters live\n in embeds, full membership walk on 404 probes). These are annotated\n as `plan-checked: KNOWN DEBT` describing the fix each needs (fenced\n functions like get_reader_feed) rather than silently suppressed.\n getNewFeed's discover query is the one genuinely safe hit — its\n newest-first walk is the intended access path because the filters\n exclude only a small minority of recent documents.\n- .claude/skills/supabase-query-plans: the full explanation — why the\n LATERAL shape is structural (no index or ANALYZE can fix it), the\n three safe query shapes, the fenced-RPC recipe with its costs, and\n how to verify a plan against skewed synthetic data — plus a CLAUDE.md\n pattern bullet pointing at it.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_01XtiQx6hT88QJjnaF36qszZ\n\n* Drop the generateFeed fallback path\n\nThe migration deploys with the same push, so serve the feed from\nget_publication_feed_docs unconditionally and let a query failure\nsurface as a retryable 500 like the publication lookup above it.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_01XtiQx6hT88QJjnaF36qszZ\n\n* Fold the query-plan guidance into the CI check\n\nThe check's header and error message carry the fix recipes and\nsuppression rules directly, so the separate skill doc is redundant.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_01XtiQx6hT88QJjnaF36qszZ\n\n---------\n\nCo-authored-by: Claude ","tree":"4b86c80f9e8d847834c5c6fff39f6f7c4bdf6cc6"},"mode":"0040000","name":"migrations","size":0},{"lastCommit":{"author":{"email":"jared@awarm.space","name":"Jared Pereira","when":"2025-08-27T22:39:27.000000+09:00"},"committer":{"email":"jared@awarm.space","name":"Jared Pereira","when":"2025-08-27T22:39:27.000000+09:00"},"hash":"17e431e63f16730a8c7236d05af6b6c5e43e13d8","message":"increase max connections in pool\n","tree":"e92e8720619128281dd5e36b493c2d37d6b7c0e1"},"mode":"0100644","name":"pool.ts","size":373},{"lastCommit":{"author":{"email":"jared@awarm.space","name":"Jared Pereira","when":"2024-05-15T12:33:03.000000-04:00"},"committer":{"email":"jared@awarm.space","name":"Jared Pereira","when":"2024-05-15T12:33:03.000000-04:00"},"hash":"a805b34a3b8e448f972a8e0d7fbfbb2cbcbc59e0","message":"init\n","tree":"2d34c3b4d4923e2f3c5feefb982c9764b2c797c1"},"mode":"0100644","name":"seed.sql","size":0},{"lastCommit":{"author":{"email":"jared@awarm.space","name":"Jared Pereira","when":"2025-05-21T12:14:20.000000-04:00"},"committer":{"email":"noreply@github.com","name":"GitHub","when":"2025-05-21T12:14:20.000000-04:00"},"hash":"829f0a4fc15b0c342eb9a47ae4425dc106947419","message":"Merge pull request #135 from hyperlink-academy/feature/create-publication\n\nFeature/create publication","tree":"3b62f3ee03c7b2e3f3ee19f95dbdc8e13c619467"},"mode":"0100644","name":"serverClient.ts","size":279},{"lastCommit":{"author":{"email":"jared@awarm.space","name":"Jared Pereira","when":"2026-07-18T12:33:41.000000-07:00"},"committer":{"email":"noreply@github.com","name":"GitHub","when":"2026-07-18T15:33:41.000000-04:00"},"hash":"b108a055fd1f8eb74b4e6a27b829d895cce97740","message":"Cut Supabase + Vercel spend without changing user-facing behavior (#355)\n\n* Suppress yjs realtime broadcasts when no other peer is subscribed\n\nA solo editor streams doc updates every 50ms and cursor awareness every\n80ms into an empty channel — every message billed by supabase, delivered\nto nobody. Solo sessions are the common case, so this was the bulk of\n~7.9M billed realtime messages/month.\n\nTrack channel membership via presence and drop doc-update/awareness\nbroadcasts while no other peer is present. Late joiners converge through\nreplicache exactly as they already did for updates sent before they\nsubscribed. Recently received broadcasts also count as peer presence so\npre-presence clients keep working across the deploy boundary.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_018MbcWeXrpeshUJLFDJKzek\n\n* Cut database and storage egress in the hot read paths\n\nUncached supabase egress ran 839GB/mo against 53GB cached. Three\ncontributors addressed here:\n\n- Replicache pulls return a full document snapshot every time, and every\n open tab polled one per minute. Stretch the idle poll to 5 minutes and\n pull explicitly when the poke channel resubscribes after a drop, so\n convergence still happens immediately after a missed-poke disconnect.\n Worst case for a poke lost on a live socket is now 5 minutes of\n staleness for a passive viewer instead of 1.\n- The bsky feed skeleton endpoints selected entire document rows\n (including full content jsonb, 25 at a time, on unbounded external\n traffic) to read only a post ref. Project just uri/sort_date/refs.\n- storage-js expects cacheControl in seconds; passing a full header\n string stored a malformed Cache-Control (max-age=public, ...) on every\n uploaded image, defeating CDN caching of user assets.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_018MbcWeXrpeshUJLFDJKzek\n\n* Resize images with sharp instead of Supabase image transforms\n\nSupabase bills $5 per 1,000 origin images transformed per month\n(19,275 last cycle). Replace all three transform pipelines with sharp,\nwhich the repo already uses for cover thumbs:\n\n- atproto_images: resize the cached PDS blob in-function rather than\n via storage.download({transform}); also drops the per-request list()\n existence probe and reuses fetched bytes instead of re-downloading.\n- link_previews: store the screenshot already downscaled to its 240x208\n display size and serve the object directly, transform-free.\n- next/image loader: point at a new /api/resized_images sharp proxy\n (originals come off the storage CDN; responses are edge-cached for a\n year) instead of the render/image endpoint.\n\nOutput dimensions and no-upscale behavior match imgproxy's; EXIF\norientation is applied explicitly via rotate().\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_018MbcWeXrpeshUJLFDJKzek\n\n* Serve image bytes from Supabase's CDN via redirect, not through Vercel\n\nThe Vercel invoice shows fast data transfer already ~500GB past the\nincluded 1TB, so every image byte streamed through these routes bills at\n$0.15/GB — worse than the Supabase egress the sharp rewrite was saving,\nand cover/doc images are pure byte volume. Store each resized variant\n(and the cached original) in storage once and 302 to its public URL:\nbytes then leave via Supabase's CDN as cached egress ($0.03/GB with free\nheadroom) and Vercel serves only a year-long-edge-cached redirect.\n\nensureOriginalCached also repairs legacy objects stored with the\nmalformed 'max-age=public, ...' Cache-Control by re-uploading them once\nwith a well-formed value, since redirecting to an uncacheable object\nwould forfeit the CDN saving. Streaming from the PDS remains the last\nresort when nothing could be cached.\n\nTradeoff: one extra redirect hop per image on a cold browser cache.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_018MbcWeXrpeshUJLFDJKzek\n\n* Cut Vercel Fluid compute burned on screenshots, favicons, and push logging\n\nFluid bills provisioned memory for full instance wall time, so the\nmulti-second remote-browser renders behind og-images were the main\nburn: every unfurl bot re-fetch after the 60s revalidate paid a fresh\nrender. OG cards are effectively immutable post-publish — raise\nrevalidate to a day and let the CDN serve them (stale by at most a day\nafter an edit). The share-card screenshot route had no caching at all;\nedge-cache it per url.\n\nAlso: the per-leaflet favicon was force-dynamic + no-cache, running two\nDB queries and a satori render on nearly every page load — cache it,\npicking up theme edits within the hour. Gate the per-push performance\nlog summary behind LOG_PUSH_PERFORMANCE. Stop runtime-cache writes for\narbitrary user-pasted URLs in resolveBlueskyPostUrl (near-zero hit\nrate, one billed cache write per paste).\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_018MbcWeXrpeshUJLFDJKzek\n\n* Reduce Vercel request volume and reader-page bundle weight\n\n- Serve the hot feed from a CDN-cacheable GET route. It's identical for\n every user and already 5 minutes stale from redis, but each reader's\n load paid an uncacheable POST invocation returning 50 full posts.\n Worst-case staleness goes from ~5 to ~10 minutes.\n- Widen replicache pushDelay 500ms -> 1s: halves push invocations during\n sustained typing. Live co-editing latency rides the yjs channel;\n replicache-only changes (e.g. block moves) reach collaborators ~0.5s\n later, and unsent mutations survive tab close in local storage.\n- Load the comment editor and bsky share composer on interaction instead\n of bundling them: both drag prosemirror into every public post page\n for readers who never comment or share.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_018MbcWeXrpeshUJLFDJKzek\n\n* Drop sub-1%-impact interventions\n\nRanking the branch's changes by predicted monthly savings, three fall\nunder 1% of the total (~$310/mo) because their frequency drivers are\nhuman actions, not machine traffic: quote-screenshot caching\n(share-modal opens), the push perf-log gate (sub-ms CPU per push), and\nthe no-store paste-URL resolution (a runtime-cache write per paste).\nRevert them to keep the diff to changes that pay for their risk.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_018MbcWeXrpeshUJLFDJKzek\n\n* Answer conditional feed requests with 304s\n\nThe rss route gets polled harder than any page on the site (156K\nrequests in the last transfer window), and transfer out is billed even\non CDN cache hits, so every poll paid for the same unchanged bytes.\nFeed readers nearly all send If-None-Match; derive an ETag from the\nbody — generateFeed already pins the updated stamp so an unchanged feed\nis byte-stable — and return an empty 304 on match.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_018MbcWeXrpeshUJLFDJKzek\n\n* Snap image-resize dimensions to a fixed width ladder (#358)\n\nThe resized_images and atproto_images routes accept caller-controlled\ndimensions, and every novel value mints a permanent stored variant on\ncache miss — an unauthenticated caller could mint ~2000 objects per\nimage (~4M per cid for w×h) just by walking the width space. Snap\nrequests to a 4-entry ladder shared from supabase/imageSizes.js so the\nkeyspace per image is bounded: 360/800 are the app's own\ncover-thumbnail widths, 1200 covers document-body images at retina\ndensity, 2000 is the existing cap. Snapping up (never rejecting) keeps\nURLs already living in edge and browser caches working across the\ndeploy, and off-ladder requests collapse onto the same stored objects\nbecause the snapped value keys both the sharp resize and the variant\npath. atproto_images height is snapped too rather than dropped, keeping\nold cached URLs valid while bounding the w×h grid.\n\nAlign the clients so real traffic is on-ladder before it reaches the\nedge cache: the next/image loader snaps in the browser, and\nimages.deviceSizes is set to the ladder (imageSizes emptied — its\nentries must sit below the smallest deviceSize and every icon-sized use\nalready collapses to 360 via the loader) so srcset candidates come out\nof the same four widths instead of Next's 16-entry default. The share\ncomposer's 1000px cover prefetch moves to the 1200 rung it would be\nsnapped to anyway.\n\n\nClaude-Session: https://claude.ai/code/session_01MQBgS6Lb1BrTgg2pu1Bfm4\n\nCo-authored-by: Claude \n\n---------\n\nCo-authored-by: Claude ","tree":"38933109e777b0b845a3dec50d079a863f2a12b1"},"mode":"0100644","name":"supabase-image-loader.js","size":566}],"lastCommit":{"author":{"email":"jared@awarm.space","name":"Jared Pereira","when":"2026-07-18T22:16:59.000000-07:00"},"committer":{"email":"noreply@github.com","name":"GitHub","when":"2026-07-19T01:16:59.000000-04:00"},"hash":"6ad09ee8daa82cffe9e06da89278230b66eaf9a9","message":"Prevent full-table scans in PostgREST queries with order+limit+embed (#361)\n\n* Fence the feed query plan against full documents scans\n\nThe optimized feed query selected from documents ordered by sort_date\nwith a limit while filtering through a documents_in_publications embed.\nPostgREST expresses that embed filter as a LATERAL join referencing\ndocuments.uri, which pins documents as the outer side of the plan: the\nonly way to satisfy the order + limit is to walk documents_sort_date_idx\nacross the entire table, probing the membership table for every document\nuntil 50 match. For a small or inactive publication that is a full scan\nof documents on every feed poll (reproduced locally: 200k synthetic\ndocuments, 431ms and loops=200005 on the join probe, with the limit\nnever short-circuiting because the publication's posts are the oldest).\n\nServe the feed from get_publication_feed_docs instead — the same fix the\ntag page uses for the identical trap (20260702000000): a MATERIALIZED\nCTE fences the plan to start from the publication's own membership rows\n(the documents_in_publications pkey), enable_seqscan off keeps the join\nas documents pkey probes, and only the 50 returned rows detoast their\ndata jsonb. Work is bounded by the publication's post count (0.1ms for\na 5-post publication, 33ms for a 10k-post one, same dataset).\n\nOrdering is sort_date DESC NULLS LAST, restoring the pre-optimization\nsemantics (null dates sorted as epoch 0, i.e. oldest): the replaced\nquery's sort_date.desc put null-dated documents first, which also made\nrow 0 — the Last-Modified source — a null date.\n\nSince the migration deploys separately from the code, a missing function\ndegrades to fetching the publication's rows membership-first (a shape\nthat cannot hit the trap) and sorting in JS, mirroring the tag page's\nfallback.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_01XtiQx6hT88QJjnaF36qszZ\n\n* Guard against the order+limit+embed-filter full-scan trap in CI\n\nThis repo has now shipped the same planner trap three times (tag page,\nprofile/reader feeds, publication feeds): ordering a table by its own\ncolumn with a limit while an !inner embed filters the rows. PostgREST\ncompiles the embed filter into a LATERAL join referencing the outer\ntable, which pins the join direction, so the only available plan walks\nthe order column's index across the entire table probing the embed per\nrow — a full scan whenever the filter is selective. Make the trap\nmechanically detectable instead of relying on review memory:\n\n- scripts/check-supabase-query-plans.mjs: a syntax-level check (TS\n compiler API) that flags .from() queries combining an !inner embed\n with a top-level .order() + .limit(), following chains split across\n variable reassignments (the feeds service style). Suppressed by a\n `plan-checked:` comment above .from() stating why the shape is safe;\n wired into the deploy workflow after tsc and exposed as\n `npm run check-query-plans`.\n- The sweep found two latent instances scanning documents on the feed\n service (bsky-follows and subscription skeleton feeds — selective\n follow/subscription filters in !inner embeds) and one scanning\n documents_in_publications in resolveDocumentFilter (all filters live\n in embeds, full membership walk on 404 probes). These are annotated\n as `plan-checked: KNOWN DEBT` describing the fix each needs (fenced\n functions like get_reader_feed) rather than silently suppressed.\n getNewFeed's discover query is the one genuinely safe hit — its\n newest-first walk is the intended access path because the filters\n exclude only a small minority of recent documents.\n- .claude/skills/supabase-query-plans: the full explanation — why the\n LATERAL shape is structural (no index or ANALYZE can fix it), the\n three safe query shapes, the fenced-RPC recipe with its costs, and\n how to verify a plan against skewed synthetic data — plus a CLAUDE.md\n pattern bullet pointing at it.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_01XtiQx6hT88QJjnaF36qszZ\n\n* Drop the generateFeed fallback path\n\nThe migration deploys with the same push, so serve the feed from\nget_publication_feed_docs unconditionally and let a query failure\nsurface as a retryable 500 like the publication lookup above it.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_01XtiQx6hT88QJjnaF36qszZ\n\n* Fold the query-plan guidance into the CI check\n\nThe check's header and error message carry the fix recipes and\nsuppression rules directly, so the separate skill doc is redundant.\n\nCo-Authored-By: Claude Fable 5 \nClaude-Session: https://claude.ai/code/session_01XtiQx6hT88QJjnaF36qszZ\n\n---------\n\nCo-authored-by: Claude ","tree":"4b86c80f9e8d847834c5c6fff39f6f7c4bdf6cc6"}}