Public live link item pages (/c/<id>/<item>) find an item by scanning the live link's scope and hashing each key until one matches the item id. They do this through GET /public/feeds/:id/items/:item, implemented in publicFeedItemPage in apps/api/src/feed-service.ts. The public cursor for GET /public/feeds/:id?cursor= does the same lookup at its page boundary.
The scan can read up to 2,000 rows and run up to 2,000 SHA-256 digests on each request. Nothing is cached, and no sign-in is needed. PR comments now link every file in scope to its item page, so this path gets hit more.
Options:
- Cache the scope's id-to-key list for each live link for a short TTL, using the Cache API or KV.
- Store the item id as a server-owned
file_metadata row when the file is written, and look it up through an index.
- Rate-limit the public item endpoint.
Found in review of the live link paging work (#1069).
Public live link item pages (
/c/<id>/<item>) find an item by scanning the live link's scope and hashing each key until one matches the item id. They do this throughGET /public/feeds/:id/items/:item, implemented inpublicFeedItemPageinapps/api/src/feed-service.ts. The public cursor forGET /public/feeds/:id?cursor=does the same lookup at its page boundary.The scan can read up to 2,000 rows and run up to 2,000 SHA-256 digests on each request. Nothing is cached, and no sign-in is needed. PR comments now link every file in scope to its item page, so this path gets hit more.
Options:
file_metadatarow when the file is written, and look it up through an index.Found in review of the live link paging work (#1069).