Object.defineProperty(Class, "name", { value }) is silently ignored for classes (zod errors report constructor.name === "Definition")

[proggeramlug]

Summary

Object.defineProperty(SomeClass, "name", { value: "X" }) is silently ignored for classes. The same call on a plain function works. Even Object.getOwnPropertyDescriptor(D, "name") reports the original name afterwards, so defineProperty never stored anything — .name keeps resolving through the class registry.

Deterministic, GC-independent, reproduces at d8be5f4a2 in the default configuration.

Minimal repro

class D {}
Object.defineProperty(D, "name", { value: "Renamed" });
console.log("class-name:", D.name);

function f() {}
Object.defineProperty(f, "name", { value: "RenamedFn" });
console.log("fn-name:", f.name);

class Base {}
class Sub extends Base {}
Object.defineProperty(Sub, "name", { value: "SubRenamed" });
console.log("sub-name:", Sub.name);
console.log("ctor-name:", (new (Sub as any)() as any).constructor.name);

const E = class {};
Object.defineProperty(E, "name", { value: "ExprRenamed" });
console.log("expr-name:", (E as any).name);

console.log("desc:", JSON.stringify(Object.getOwnPropertyDescriptor(D, "name")));

line	node 26.5.1	perry d8be5f4a2
class-name	Renamed	D
fn-name	RenamedFn	RenamedFn ✅
sub-name	SubRenamed	Sub
ctor-name	SubRenamed	Sub
expr-name	ExprRenamed	E
desc	{"value":"Renamed","writable":false,"enumerable":false,"configurable":true}	{"value":"D",…}

class_object_name_value (crates/perry-runtime/src/object/field_get_set/class_object_props.rs:24) does check own_data_field_by_name before falling back to class_name_for_id, so the miss looks like it is on the store side: defineProperty with key "name" on a class value never installs the own data field. Note Function.prototype.name redefinition works, so the divergence is specific to the class path (INT32 ClassRef vs heap ClassExprFresh).

Why it matters: zod

$constructor (zod/src/v4/core/core.ts) renames both the synthetic base class and the constructor function:

class Definition extends Parent {}
Object.defineProperty(Definition, "name", { value: name });
…
Object.defineProperty(_, "name", { value: name });

so under perry a caught zod error reports the wrong constructor name:

try { z.string().parse(5); } catch (e: any) { console.log(e.constructor.name); }
// node : ZodError
// perry: Definition

Any user code branching on err.constructor.name (or logging it) sees Definition for every zod error type.

Environment

Node 26.5.1 (.node-version pin), perry @ d8be5f4a2, macOS arm64. Found while investigating #7154.

Refs #7154.

[proggeramlug]

Attempted fix failed — the class-ref arm is not the site, class D {} is not an INT32 ClassRef here

Tried the fix the issue text points at and it had zero effect; recording so the next person skips it.

What I tried (reverted). In js_object_define_property's class-ref arm (object_ops/define_property.rs), split on class_prototype_ref_id: a prototype ref keeps installing an instance method, while a constructor ref with key "name" and a string value calls a new class_set_name_override, which overwrites the CLASS_NAMES entry that class_name_for_id reads.

The design still looks right to me and is worth keeping in mind:

• Every .name read funnels through class_name_for_id — the INT32 ClassRef arm in get_field_by_name.rs, the heap-class arm in class_object_props.rs, and getOwnPropertyDescriptor — so one write would fix D.name, Sub.name, and new Sub().constructor.name together.
• It must NOT go in CLASS_DYNAMIC_PROPS: that table is enumerated verbatim by the own-keys arm, and name is non-enumerable, so it would leak "name" into Object.keys(C). A String in CLASS_NAMES also keeps it GC-invisible (no root scanner).

Why it did nothing. Output after the change was byte-identical to before:

class-name: D          (node: Renamed)
sub-name:   Sub        (node: SubRenamed)
expr-name:  E          (node: ExprRenamed)
desc:       {"value":"D",...}
fn-name:    RenamedFn  ✅ (functions already work)

So Object.defineProperty(<class>, …) is not reaching that arm at all. Supporting datum from the same run: Object.defineProperty(Keep, "tag", { value: "T" }) then Keep.tag → undefined, i.e. no static define on a class lands, not just name. And Object.keys(Keep) is still ["s"], so nothing is being written anywhere.

Most likely class D {} at top level materializes as a heap OBJECT_TYPE_CLASS object, not an INT32 ClassRef, so class_ref_id(obj_value) returns None and the define falls through to the plain-object path entirely. Note class_object_name_value (the heap-class .name reader) does check own_data_field_by_name first — so if the define really is reaching the plain-object path, the own field is not being stored either, which is a second thing to explain.

Next probe, before editing anything: determine what D actually is at the defineProperty call — INT32 ClassRef vs heap OBJECT_TYPE_CLASS vs closure — and which arm of js_object_define_property the call takes. The issue text's guess that "the miss is on the store side" is right, but the store side is not the class-ref arm.

Everything reverted; nothing shipped.

[proggeramlug]

Verified fixed on current main (1ee158d). Merge commit 28c6364 from #7798 is present, and the exact test_gap_class_static_define_property_7190 parity probe passes against Node (1/1 pass, 0 failures). It covers the reported class/subclass/class-expression names, constructor.name, arbitrary static properties, descriptors, enumeration, and prototype controls. Closing as fixed by #7798.