Aliases created from the modal never resolved: create sent the normalized display name while resolution keys on the raw booru model key — so the mapping was stored under a key nothing looks up, and the prediction kept reappearing unaliased. The raw key wasn't even in the /suggestions response, so the modal couldn't send it.
Suggestion carries raw_name (the model key an alias must use) + via_alias; both serialized.
Modal alias-create sends raw_name (the fix). Aliased suggestions show an "alias" badge + "Remove alias"; "Treat as alias for…" hidden for centroid hits / already-aliased rows.
Tag-side management: TagCard ⋮ → "Aliases…" lists the model keys that fold into a tag, with remove (GET /api/tags/<id>/aliases). Creation stays in the modal suggestion flow.
Tests: full API round-trip locking the raw-key contract; list_for_tag (service + API); via_alias/raw_name on existing service tests. No migration. CI green on dev (run 977).
Aliases created from the modal never resolved: create sent the normalized display name while resolution keys on the raw booru model key — so the mapping was stored under a key nothing looks up, and the prediction kept reappearing unaliased. The raw key wasn't even in the /suggestions response, so the modal couldn't send it.
- `Suggestion` carries `raw_name` (the model key an alias must use) + `via_alias`; both serialized.
- Modal alias-create sends `raw_name` (the fix). Aliased suggestions show an "alias" badge + "Remove alias"; "Treat as alias for…" hidden for centroid hits / already-aliased rows.
- Tag-side management: TagCard ⋮ → "Aliases…" lists the model keys that fold into a tag, with remove (`GET /api/tags/<id>/aliases`). Creation stays in the modal suggestion flow.
Tests: full API round-trip locking the raw-key contract; `list_for_tag` (service + API); `via_alias`/`raw_name` on existing service tests. No migration. CI green on dev (run 977).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The headline bug: aliases created from the modal NEVER resolved. Create
sent the normalized display name ('Sword', 'Uchiha Sasuke') while
resolution keys on the raw booru model key ('sword', 'uchiha_sasuke',
case-sensitive) — so the mapping was stored under a key nothing looks up,
and the prediction kept reappearing unaliased. The raw key wasn't even in
the /suggestions response, so the modal couldn't send it.
- Suggestion now carries raw_name (the model key an alias must use) and
via_alias (surfaced via an operator alias); both serialized by the API.
- Modal alias-create sends raw_name, not display_name (the fix). Aliased
suggestions show an 'alias' badge and a 'Remove alias' action; 'Treat as
alias for…' is hidden for centroid hits (no model key) and already-aliased
rows.
- Tag-side management: TagCard ⋮ → 'Aliases…' opens a dialog listing the
model keys that fold into a tag, with remove (GET /api/tags/<id>/aliases +
AliasService.list_for_tag). Creation stays in the modal suggestion flow.
Tests: full API round-trip locking the raw-key contract (raw_name exposed →
alias authored with it → resolves + via_alias on a later image);
list_for_tag (service + API); via_alias/raw_name on the existing service
suggestion tests. No migration.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Aliases created from the modal never resolved: create sent the normalized display name while resolution keys on the raw booru model key — so the mapping was stored under a key nothing looks up, and the prediction kept reappearing unaliased. The raw key wasn't even in the /suggestions response, so the modal couldn't send it.
Suggestioncarriesraw_name(the model key an alias must use) +via_alias; both serialized.raw_name(the fix). Aliased suggestions show an "alias" badge + "Remove alias"; "Treat as alias for…" hidden for centroid hits / already-aliased rows.GET /api/tags/<id>/aliases). Creation stays in the modal suggestion flow.Tests: full API round-trip locking the raw-key contract;
list_for_tag(service + API);via_alias/raw_nameon existing service tests. No migration. CI green on dev (run 977).🤖 Generated with Claude Code
The headline bug: aliases created from the modal NEVER resolved. Create sent the normalized display name ('Sword', 'Uchiha Sasuke') while resolution keys on the raw booru model key ('sword', 'uchiha_sasuke', case-sensitive) — so the mapping was stored under a key nothing looks up, and the prediction kept reappearing unaliased. The raw key wasn't even in the /suggestions response, so the modal couldn't send it. - Suggestion now carries raw_name (the model key an alias must use) and via_alias (surfaced via an operator alias); both serialized by the API. - Modal alias-create sends raw_name, not display_name (the fix). Aliased suggestions show an 'alias' badge and a 'Remove alias' action; 'Treat as alias for…' is hidden for centroid hits (no model key) and already-aliased rows. - Tag-side management: TagCard ⋮ → 'Aliases…' opens a dialog listing the model keys that fold into a tag, with remove (GET /api/tags/<id>/aliases + AliasService.list_for_tag). Creation stays in the modal suggestion flow. Tests: full API round-trip locking the raw-key contract (raw_name exposed → alias authored with it → resolves + via_alias on a later image); list_for_tag (service + API); via_alias/raw_name on the existing service suggestion tests. No migration. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>