packages/react/runtime/src/debug/describeInvalidValue.ts (1)

5-25: Make descriptions more informative (arrays) and guard very long strings.

Current fallback for objects is fine, but two small wins:

• Identify arrays explicitly to reduce confusion.
• Truncate very long strings in messages to avoid noisy logs.

Suggested change:

 export function describeInvalidValue(value: unknown): string {
+  const MAX_STRING_PREVIEW = 120;
   if (value === null) {
     return 'null';
   }
   if (value === undefined) {
     return 'undefined';
   }
   if (typeof value === 'function') {
     return `function ${value.name || '(anonymous)'}`;
   }
   if (typeof value === 'string') {
-    return `string "${value}"`;
+    const s = value.length <= MAX_STRING_PREVIEW
+      ? value
+      : value.slice(0, MAX_STRING_PREVIEW) + '…';
+    return `string "${s}"`;
   }
   if (typeof value === 'number' || typeof value === 'bigint' || typeof value === 'boolean') {
     return `${typeof value} ${String(value)}`;
   }
   if (typeof value === 'symbol') {
     return `symbol ${String(value)}`;
   }
+  if (Array.isArray(value)) {
+    return `array(length ${value.length})`;
+  }
   return `unexpected ${typeof value}`;
 }

packages/react/runtime/__test__/debug/describeInvalidValue.test.ts (1)

29-32: Add coverage for arrays and very long strings.

Consider asserting:

• arrays: expect(...).toBe('array(length 3)');
• long strings are truncated with an ellipsis.

Keeps tests aligned with more descriptive messaging if adopted.

packages/react/runtime/__test__/snapshot/workletEvent.test.jsx (2)

424-508: Strengthen expectation to validate value description is surfaced.

In addition to checking the attribute name, assert the error message includes the described invalid value (e.g., contains 'function'). This guards the improved error formatting.

Example:

-        expect(reportErrorSpy).toHaveBeenCalledWith(
-          expect.objectContaining({
-            message: expect.stringContaining('"main-thread:bindtap"'),
-          }),
-        );
+        expect(reportErrorSpy).toHaveBeenCalledWith(
+          expect.objectContaining({
+            message: expect.stringContaining('"main-thread:bindtap"'),
+          }),
+        );
+        expect(reportErrorSpy.mock.calls[0][0].message).toEqual(
+          expect.stringContaining('function')
+        );

---

510-559: Dev warnings: assert more of the formatted context.

Also assert the message includes:

• element tag ()
• snapshot id and name
• the described value, e.g., string "not-a-worklet"

Example:

-      expect(getErrorMessage(reportErrorSpy)).toContain('"main-thread:bindtap" on <view>');
+      const msg = getErrorMessage(reportErrorSpy);
+      expect(msg).toContain('"main-thread:bindtap" on <view>');
+      expect(msg).toContain('snapshot 42 "TestSnapshot"');
+      expect(msg).toContain('string "not-a-worklet"');

packages/react/runtime/src/snapshot/workletEvent.ts (2)

16-34: Tune wording for accuracy and consistency.

Message says “expected a main-thread function,” while the runtime expects a worklet-like object. Consider “main-thread worklet/handler” to reduce ambiguity.

-  const message = `"${eventAttr}" on <${elementTag}> (snapshot ${elementId} "${snapshotName}") expected `
-    + 'a main-thread function but received '
+  const message = `"${eventAttr}" on <${elementTag}> (snapshot ${elementId} "${snapshotName}") expected `
+    + 'a main-thread worklet/handler but received '
     + `${describeInvalidValue(value)}. Did you forget to add a "main thread" directive to the handler?`;

---

47-53: DEV validation: also reject arrays and obviously non‑worklet objects.

Today only non-objects are rejected. Arrays or plain objects without worklet markers slip through and may fail later. Recommend expanding the DEV check:

-  const rawValue = snapshot.__values![expIndex];
-  if (__DEV__ && rawValue !== null && rawValue !== undefined && typeof rawValue !== 'object') {
-    reportInvalidWorkletValue(snapshot, elementIndex, workletType, eventType, eventName, rawValue);
-    return;
-  }
+  const rawValue = snapshot.__values![expIndex];
+  if (__DEV__) {
+    const isObject = rawValue !== null && rawValue !== undefined && typeof rawValue === 'object';
+    const isArray = Array.isArray(rawValue);
+    const isWorkletLike =
+      isObject && !isArray && (('_wkltId' in (rawValue as any)) || ('_lepusWorkletHash' in (rawValue as any)));
+    if (!isObject || isArray || !isWorkletLike) {
+      reportInvalidWorkletValue(snapshot, elementIndex, workletType, eventType, eventName, rawValue);
+      return;
+    }
+  }

This keeps prod behavior unchanged but gives earlier, clearer feedback in DEV.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Learnt from: gaoachao
PR: lynx-family/lynx-stack#1736
File: .changeset/spotty-experts-smoke.md:1-3
Timestamp: 2025-09-12T09:43:04.847Z
Learning: In the lynx-family/lynx-stack repository, private packages (marked with "private": true in package.json) like lynx-js/react-transform don't require meaningful changeset entries even when their public APIs change, since they are not published externally and only affect internal development.

Learnt from: gaoachao
PR: lynx-family/lynx-stack#1736
File: .changeset/spotty-experts-smoke.md:1-3
Timestamp: 2025-09-12T09:43:04.847Z
Learning: In the lynx-family/lynx-stack repository, empty changeset files (containing only `---\n\n---`) are used for internal changes that modify src/** files but don't require meaningful release notes, such as private package changes or testing-only modifications. This satisfies CI requirements without generating user-facing release notes.