7 Commits

Include renames

Author	SHA1	Message	Date
openhands	f3407ebfdf	fix(imaging): support .hab assets, cache avatars/badges, harden routes ... The hotel moved from .nitro to .hab bundles, so the imager must treat .hab like .nitro and the public avatar endpoints must accept the figure strings the client sends (including extra trailing segments such as `.0`, which the old FIGURE_RE rejected with a 400). - imager-upstream: relax FIGURE_RE, extend parseAvatarQuery test coverage - api/imaging/avatar + /imaging: shared validation, placeholder and ETag/304 - api/imaging/badge: single-flight upstream fetch and conditional responses - imager-http/imager-png: strong ETag helpers and APNG passthrough guard - csp + next/image: unoptimized external images, tightened CSP - deps: override postcss-selector-parser to ^7.1.6 - also fold in the pending drizzle draft snapshot and stray test cleanup	2026-10-14 20:40:50 +02:00
openhands	155bf750c3	fix(cache): bound grace windows, cap render queues, and drop the useless estimate ... Follow-up to f81b114b, addressing the three ways that commit could make things worse rather than better. All three were verified against the real database or by breaking the test and watching it fail. - The grace window is now capped at 120s. A window is a cushion for the TTL boundary, not a second TTL, but the call sites treated it as the latter: the 5 min values/staff routes and the 10 min teams route asked for a window as long as or longer than their own TTL, so a single large staleMs silently doubled how far behind a value could be served. Nothing marked those as unsafe, because nothing looked wrong. The cap lives in the cache rather than at the call sites so no future route can reintroduce it. Routes that asked for less than 120s (the 10s online poll, the 20s news cache) are unchanged, so their intended cushion still does its job. - A request no longer queues behind an arbitrarily old render. Sharing a render is what collapses a cold-cache stampede into one render, but a hung render used to hold up everyone who arrived after it. A newcomer past 2s now serves the placeholder instead of waiting, reusing the ImagerUnavailableError path that "both upstreams down" already takes. The caller that actually started the render keeps waiting, which is correct: it is the one whose image this is. When the join window is removed the new test hangs for the full 10s it was meant to prevent, which is the tail this bounds. - The information_schema row-count estimate is gone; the counters are exact again. Running it against the live database: users 165, rooms 92, camera_web 0, and the estimate was 0.00% off on all three. At 165 rows an index scan is cheaper than the extra round trip the estimate needed, so the optimisation bought nothing and traded a guaranteed-correct member count for an approximation that InnoDB would only make less accurate as the table grows. The exactness is now pinned by tests: a real zero stays zero, a database error propagates instead of becoming a number, and each counter counts the table it claims to. The module stays, because the homepage and the boot warm-up writing different values to the same cache key is its own bug. The module comment records the measured numbers, because "COUNT(*) is too slow" sounds true in the abstract and is false here. 3223 tests pass.	2026-09-25 18:55:33 +02:00
openhands	f81b114b69	perf(cache): single-flight avatar renders, cacheable public reads, cheap row counts ... Three separate things that were each costing more than they needed to on the hot path. - Single-flight avatar renders. The disk cache was checked first and a miss went straight to the upstream, with nothing shared between callers, so a page requesting dozens of avatars at once turned N concurrent requests for one figure into N renders. A render is the most expensive operation this app does, and the duplication happened exactly when the cache had nothing to offer. Eight concurrent requests now cause one render instead of eight. The map lives on globalThis because Next can evaluate the module more than once per process, and two copies would each start their own render. - Let public read-only routes be cached by a shared cache. Every JSON response was `cache-control: no-store`, so a CDN in front of the app could not answer any of it and every request reached the origin. publicCacheControl() opts a route in with s-maxage and stale-while-revalidate, using the same TTL as the server-side cache so the two layers cannot disagree. The default stays no-store: most routes here are personalised, admin-only or auth-dependent. /api/badges/leaderboard is deliberately left alone because it returns per-viewer rank entries to signed-in callers. Note this only takes effect once a cache rule exists for /api/* at the CDN, or the explicit `cache: "no-store"` is dropped from the client fetches (24 files do that today, including the /api/online poll). The headers alone are inert until one of those happens. - Take the homepage row counts from the storage engine estimate instead of COUNT(*), which walks an index and gets slower as the tables grow. A missing or zero estimate falls back to the exact count rather than ever showing a wrong zero. The online count stays exact: it is an indexed read over a small subset and a few seconds of drift reads as broken rather than approximate. The counters move into one module because the homepage and the boot warm-up populate the same cache keys, so two implementations would race to write different values into the same entry. 3223 tests pass.	2026-09-25 18:42:23 +02:00
openhands	f490fcc9da	fix(imaging): stop caching fallback renders ... A fallback render drops the requested effect and is only a degraded stand-in, so writing it to the 30 day disk cache kept serving the worse image long after the local renderer recovered. Cache primary renders only and let the next request pick up the real render.	2026-09-24 23:34:54 +02:00
openhands	fe5a7a6185	fix(imaging): keep avatars rendering, cacheable and reliably timed ... Effect renders need a little over 4s, which the 4s primary timeout cut off, so every avatar with the default effect fell through to an unreachable public fallback and rendered as a placeholder. Raise the primary budget above the observed render cost and shorten the fallback budget. Also stop the proxy from stamping no-store over the avatar and media responses, so browsers keep the long-lived Cache-Control the route already sends, and recreate the imaging cache directories with the container user on every deploy, since root ownership made those cache writes fail silently.	2026-09-24 23:22:28 +02:00
openhands	8a66db4ed7	fix(imaging): make avatar and badge images resilient to upstream outages ... - Add persistent disk cache for rendered avatars/badges (storage/imaging) so repeats never touch the flaky local renderer and cached renders survive upstream downtime - Serve cache-first with stale-on-error; cut primary/fallback timeouts from 10s/6s to 4s/4s so failing images cannot stall pages - Avatar proxy now returns a graceful 200 silhouette instead of 502 when no renderer can produce a figure, so no broken-image glyphs appear - Badge endpoint becomes a caching proxy trying configured CDN, public Habbo CDN and local /swf copy in order, and drops the fragile IP rate limit that could blank badge streams - Route all site badge images (profile, me, badges, apply pages) through the cached proxy instead of hot-linking images.habbo.com	2026-09-20 12:58:55 +02:00
openhands	1df1ffc3e9	Make avatar imager resilient with upstream fallback everywhere	2026-09-14 17:35:36 +02:00