Matt Miller 36f9a6fdef feat(assets): preserve insertion order on tag retrieval ... The /api/assets response previously sorted tags alphabetically via .order_by(Tag.name.asc()). That breaks the structurally meaningful "root category first, then subpath" invariant the path-collapsing change relies on: alphabetical sort puts a custom user tag (or even the bare "models" root) at unpredictable positions, so positional access like tags[1] is not reliable on local. Cloud already preserves insertion order — its Ent WithTags() eager- load has no explicit ORDER BY, so Postgres returns rows in physical insertion order. Local's composite primary key on (asset_reference_id, tag_name) means SQLite walks the index in tag_name order even without an explicit ORDER BY, so just dropping the clause isn't enough. Switching to ORDER BY added_at ASC, tag_name ASC keeps the path tags inserted via set_reference_tags in their original order (microsecond-resolution timestamps disambiguate same-batch inserts; tag_name is a deterministic tiebreaker for the rare collision case). Custom tags added later via add_tags_to_reference land after the path tags in their own added_at bucket. Applies to both response-shaping queries: - list_references_page (GET /api/assets, tag_map join) - fetch_reference_asset_and_tags (GET /api/assets/{id}) Catalog/histogram queries in app/assets/database/queries/tags.py keep their alphabetical sort — those endpoints are listing all tags, not per-asset tags, and alphabetical is the right shape there.		2026-05-19 20:14:01 -07:00
..
queries	feat(assets): preserve insertion order on tag retrieval	2026-05-19 20:14:01 -07:00
models.py	feat(assets): align local API with cloud spec (#12863)	2026-03-16 12:34:04 -07:00