Gitea Actions Runner Test / test-job (push) Successful in 0s
CI / check (push) Successful in 29s
CI / tests-integration (push) Successful in 1m33s
CI / tests-unit (push) Successful in 1m33s
CI / tests-ui (push) Successful in 2m21s
CI / preflight (push) Skipped
CI / deploy (push) Successful in 1m53s
The resync route rebuilt every entry from items_base plus the *official Habbo* furnidata. A classname that only exists on a retro hotel (leet.ws and friends) is absent from the official set, so lookupOfficialHabboFurni returned null and the entry was written with revision 0, category "unknown" and an empty description — even though the clone import had those exact values available at import time from the source's own furnidata. - resync/route.ts: when a classname is genuinely missing from official Habbo, fall back to the configured clone sources. Their furnidata is indexed by normalized classname and each entry is coerced into the OfficialHabboFurniEntry shape, which is the same JSON shape, so it drives the existing buildFurniEntry fallbacks for revision, category, name, description, defaultdir, partcolors, specialtype, furniline, environment, rare and bc. items_base stays authoritative for id, spriteId and dims, and public_name still wins over the source name, matching the import. The index is memoized per request, not at module scope: a module-level cache would pin the source list for the life of the process and a source added later would never be picked up. fetchSourceFurnidata already caches per URL, so this costs one parse rather than a network round-trip. Disabled sources and sources that fail to respond are skipped, so an unreachable hotel degrades to the previous items_base-only behaviour instead of failing the run. Official Habbo still wins whenever it has the classname, so existing behaviour is unchanged for everything but the retro-only case. Applies to every resync mode, so the pre-existing ?missing=1 sweep picks this up too.