Filed unassigned by the dev seat working objectui#6531 (session session_011SfZeFWrhGLHmfq61xbz4q), spotted while enumerating every caller of getRecordDisplayName for that card's producer census. Observational — dead code plus a second de-facto contract — so it carries finding and no pm:queue. Duplicate scan before filing: 244 open objectui issues enumerated via the REST list endpoint (3 full pages) and grepped for getRecordDisplayName / record-title / display name / nameField; the only subject hit is #6531 (positive control).
What is there
apps/console/src/utils.ts:73:
exportfunctiongetRecordDisplayName(objectDef: any,record: any): string{if(objectDef?.titleFormat){returnformatRecordTitle(objectDef.titleFormat,record);}// Fallback: Try common name fieldsreturnrecord?.name||record?.title||record?.label||record?.id||record?._id||'Untitled';}This is one of the ~6 divergent per-surface resolvers ADR-0079 unified into @object-ui/core#getRecordDisplayName — the module docblock names the family and the exact defect ("each fell back to a slightly different hard-coded list … an object whose records carry their name in activity_name therefore rendered Untitled everywhere"). Every other surface was migrated. This copy was not, and it reproduces the pre-ADR-0079 behaviour precisely:
- it never reads
nameField, the canonical pointer ADR-0079 Phase 2 introduced; - it never reads
displayNameField; - it does no type-aware derivation and no
*_name affix probe — so activity_name still renders as the record id; - it ranks the deprecated render-only
titleFormatfirst, which is the ordering ADR-0079 Phase 2 explicitly inverted (a declared field now wins over the legacy template); - its floor returns the raw
id/_id rather than Record #<id>.
Two distinct problems, and the second is why this is worth filing
It is dead. Grepping apps/console/src for getRecordDisplayName returns only the definition — nothing imports it. The sibling formatRecordTitle in the same file has no console consumer either.
It is also a trap. It is exported from a plain utils.ts that other console modules already import from (e.g. AppManagementPage.tsx pulls resolveKeyedI18nLabel out of it). The next console surface that needs a record title has a same-named, same-signature function sitting one import away, and picking it up is silent: no type error, no lint finding, no test — just titles that quietly ignore every declared pointer. That is the exact failure ADR-0079 was written to end, re-armed.
Suggested resolution
Delete both getRecordDisplayName and formatRecordTitle from apps/console/src/utils.ts. If a console surface ever needs either, @object-ui/core exports both (getRecordDisplayName, formatTitleTemplate) and the console already depends on it. A re-export aliasing the core function would also close the trap, but deleting is better: it removes the second spelling instead of blessing it.
Worth confirming the liveness read at the moment of the fix rather than trusting this one — the console is edited by several seats.
Refs: objectui#6531 (the census that surfaced it) · ADR-0079 · packages/core/src/utils/record-title.ts (the module docblock naming the unified family).
Generated by Claude Code
Generated by Claude Code
Filed unassigned by the dev seat working objectui#6531 (session
session_011SfZeFWrhGLHmfq61xbz4q), spotted while enumerating every caller ofgetRecordDisplayNamefor that card's producer census. Observational — dead code plus a second de-facto contract — so it carriesfindingand nopm:queue. Duplicate scan before filing: 244 open objectui issues enumerated via the REST list endpoint (3 full pages) and grepped forgetRecordDisplayName/record-title/display name/nameField; the only subject hit is #6531 (positive control).What is there
apps/console/src/utils.ts:73:This is one of the ~6 divergent per-surface resolvers ADR-0079 unified into
@object-ui/core#getRecordDisplayName— the module docblock names the family and the exact defect ("each fell back to a slightly different hard-coded list … an object whose records carry their name inactivity_nametherefore rendered Untitled everywhere"). Every other surface was migrated. This copy was not, and it reproduces the pre-ADR-0079 behaviour precisely:nameField, the canonical pointer ADR-0079 Phase 2 introduced;displayNameField;*_nameaffix probe — soactivity_namestill renders as the record id;titleFormatfirst, which is the ordering ADR-0079 Phase 2 explicitly inverted (a declared field now wins over the legacy template);id/_idrather thanRecord #<id>.Two distinct problems, and the second is why this is worth filing
It is dead. Grepping
apps/console/srcforgetRecordDisplayNamereturns only the definition — nothing imports it. The siblingformatRecordTitlein the same file has no console consumer either.It is also a trap. It is
exported from a plainutils.tsthat other console modules already import from (e.g.AppManagementPage.tsxpullsresolveKeyedI18nLabelout of it). The next console surface that needs a record title has a same-named, same-signature function sitting one import away, and picking it up is silent: no type error, no lint finding, no test — just titles that quietly ignore every declared pointer. That is the exact failure ADR-0079 was written to end, re-armed.Suggested resolution
Delete both
getRecordDisplayNameandformatRecordTitlefromapps/console/src/utils.ts. If a console surface ever needs either,@object-ui/coreexports both (getRecordDisplayName,formatTitleTemplate) and the console already depends on it. A re-export aliasing the core function would also close the trap, but deleting is better: it removes the second spelling instead of blessing it.Worth confirming the liveness read at the moment of the fix rather than trusting this one — the console is edited by several seats.
Refs: objectui#6531 (the census that surfaced it) · ADR-0079 ·
packages/core/src/utils/record-title.ts(the module docblock naming the unified family).Generated by Claude Code
Generated by Claude Code