Problem
formatWithTemplate in ui/src/utils/packetTypes.ts captures the |* suffix from template placeholders via the regex group (\|\*)? but never checks whether it was present. This means any field with a wildcard_value set renders as * regardless of whether the template placeholder uses {field|*} or plain {field}.
The server metadata contract (crates/core/src/packet_meta.rs:46-48) documents |* as indicating wildcard-display, so the formatter should respect it.
Current impact
No practical impact today — all built-in fields with null wildcards that appear in templates already use {field|*}, and fields with null wildcards that don't use |* aren't referenced in any template. However, custom plugin metadata could trigger the issue.
Fix
Check whether the matched placeholder includes |* before rendering the wildcard:
if (rule && 'wildcard_value' in rule && _m.includes('|*')) {
isWildcard = deepEqual(value, rule.wildcard_value);
}Context
Found during review of #460 (comment: #460 (comment)). Pre-existing behavior — the old code also never checked the |* group.
Problem
formatWithTemplateinui/src/utils/packetTypes.tscaptures the|*suffix from template placeholders via the regex group(\|\*)?but never checks whether it was present. This means any field with awildcard_valueset renders as*regardless of whether the template placeholder uses{field|*}or plain{field}.The server metadata contract (
crates/core/src/packet_meta.rs:46-48) documents|*as indicating wildcard-display, so the formatter should respect it.Current impact
No practical impact today — all built-in fields with null wildcards that appear in templates already use
{field|*}, and fields with null wildcards that don't use|*aren't referenced in any template. However, custom plugin metadata could trigger the issue.Fix
Check whether the matched placeholder includes
|*before rendering the wildcard:Context
Found during review of #460 (comment: #460 (comment)). Pre-existing behavior — the old code also never checked the
|*group.