4.10.1 regression: raw Record() on sys_dictionary emits minted GUIDs instead of table names in <reference>

[dalestubblefield]

Summary

@servicenow/sdk 4.10.1 has a serialization regression affecting raw Record() declarations on sys_dictionary. The reference property (which per the platform schema must hold a table name) is emitted into the built XML as a minted GUID instead of the declared name. Installing such a build writes a dangling hex value into sys_dictionary.reference, which breaks the reference field platform-wide: blank display values, and the field can be omitted from Table API responses. Recovery required manually patching the affected sys_dictionary records on the instance.

Version 4.9.2 building the identical source emits the correct value. (4.10.0 untested.)

Minimal repro

// src/fluent/example.now.ts
import '@servicenow/sdk/global'
import { Record } from '@servicenow/sdk/core'

Record({
    $id: Now.ID['example_field'],
    table: 'sys_dictionary',
    data: {
        name: 'x_my_scope_my_table',
        element: 'account_executive',
        column_label: 'Account Executive',
        internal_type: 'reference',
        max_length: 32,
        reference: 'sys_user', // table NAME, per sys_dictionary schema
        sys_scope: '<scope sys_id>',
        sys_package: '<scope sys_id>',
    },
})

now-sdk build with 4.9.2 emits (correct):

<reference>sys_user</reference>

now-sdk build with 4.10.1 emits (broken):

<reference name="sys_user">00787a2238064c58b91cb6384f89f647</reference>

The hex value is a freshly minted UUIDv4 (dashes stripped), different on every build. It looks like the build pipeline now treats the reference column value as a RecordId to resolve through the keys registry: when the referenced table happens to be declared in the same project, the emitted value is that table's keys.ts id instead (which also never matches the platform-assigned sys_db_object sys_id, since the platform mints its own at install time); for tables outside the project (sys_user, customer_account, etc.) a random GUID is minted per build.

Either way the installed value is a 32-char hex that can never resolve, because the platform resolves sys_dictionary.reference by table name (the reference link on the record is literally sys_db_object?name=<value>).

Notes

• Typed Column() declarations inside Table() are NOT affected on either version; only raw Record() on sys_dictionary.
• Raw Record() dictionary entries are common when capturing existing instance fields with their original sys_ids (including fields added to OOB tables like customer_account, where the typed Table() DSL is not an option), and now-sdk transform itself generates this pattern.
• Environment: Node 20.x, Linux and macOS, scoped app project.
• We have pinned back to 4.9.2 and added a post-build check that greps the dist for the corruption signature before any install; happy to share details or test a fix build.

[dalestubblefield]

Update: tested 4.10.0 as well. It has the same defect (identical corruption signature, same fields affected, fresh GUID per build). So the regression was introduced in 4.10.0, and 4.9.2 is the latest release that serializes raw Record() sys_dictionary reference values correctly.

[harishkumar-srinivas]

@dalestubblefield Thank you for reporting, I will log a defect for this and fix it in the upcoming release.