plugin-calendar: an authored onEventClick reaches CalendarView through the spread and throws an UNCAUGHT error on click — needs a contract decision, not a strip #4453

Measured while grading #4433's collision surface (that card's condition 1b: sweep the renderer's other computed props for the same authored-key overwrite exposure). events was crash-capable and is fixed. This one is the remaining exposure, and it is filed rather than fixed because closing it needs a decision the #4433 ruling did not cover.

The exposure

calendar-view's renderer passes onEventClick={handleEventClick} and then spreads {...props} after it. Anything arriving under that key wins — the same shape #4433 fixed for events.

Measured, both channels, before and after #4433's fix (unchanged by it):

Note the failure mode is worse than an error boundary, which is why it is not simply cosmetic: React does not route event-handler errors to SchemaErrorBoundary, so this surfaces as an uncaught window error. The calendar keeps looking fine and its click handling is dead.

Why this was not fixed alongside events

The two keys are not the same case, and the difference is what needs deciding.

events is injected metadata: SchemaRenderer forwards a node's events key as a prop, no code in the renderer layer consumes it, and no host has a reason to pass one to this renderer. Dropping it is free.

onEventClick arrives through the same channel for two very different producers:

1. an SDUI author writing JSON — the value can never be a function, so it is always broken; and
2. a React host rendering SchemaRenderer schema={…} onEventClick={fn} — the trailing ...props spread makes this work today, and it is the component's genuine escape hatch (the same passthrough MetricWidget deliberately keeps).

The key name cannot separate them; only the value's type can. So the options are:

• A. Strip onEventClick unconditionally at the renderer, like events. Simple and consistent, but it removes a host path that works today — exactly what plugin-calendar: authoring events on a calendar-view node crashes the component — the SDUI action object overwrites the computed CalendarEvent array #4433's ruling forbade doing silently.
• B. Drop it only when it is not a function. Closes the authored hazard, keeps the host path. But value-type discrimination in a consumer is the lenient-coercion shape AGENTS.md #0.1 rejects, and it makes the rule invisible at authoring time.
• C. Reject it at authoring. onEventClick is not in this widget's registry inputs and not in the spec's node vocabulary, so a publish-time validator could refuse it loudly — contract-first, and it generalizes past this one key to every on* prop of every widget.
• D. The finding(plugin-dashboard): the #3291 toDomProps whitelist stops at packages/fields — SDUI widgets elsewhere still close their DOM leak by hand, if at all #4425 phase-2 whitelist. A spread bounded by declaration would close this as a side effect, together with the leak class the sweep measured.

C and D are the same direction at two altitudes and are probably the real answer; A and B are local patches. This is left for triage rather than guessed at.

Same grading round, for the record: className is not exposed — the renderer destructures it out of its own props, so the rest object cannot carry it, and SchemaRenderer sets className after the node's props container anyway (measured: an authored props.className never reaches the region).

Related: #4433 (the events collision, fixed), #4425 (the phase-2 whitelist question), #4357 / #4428 (the deny-list precedent).

Generated by Claude Code