eca_render: action_base.name typed as machine_name contradicts the plugin's documented "][" nesting syntax

Problem/Motivation

modules/render/config/schema/eca_render.schema.yml declares:

eca_render.action_base:
  type: mapping
  label: 'Render action base config'
  mapping:
    name:
      type: machine_name
      label: 'Machine name'

But the plugin's own field description explicitly documents the opposite:

Optionally define a machine name of this render element. It will be made available under that name in the render array of the current event in scope. Nested elements can be set with using "][" brackets, for example details][title. This field supports tokens.

][ is not valid in a machine_name. So the documented, supported and load-bearing syntax for nesting render elements is rejected by the config schema. Every nested render element produces a violation:

The "contract_container][sign_contract" machine name is not valid.
The "container_animals][view" machine name is not valid.

The machine_name type also disallows the tokens the description says the field supports.

This is a schema bug, not a configuration bug — the values are correct and functional. It is important that it is understood that way, because "correcting" these values to satisfy the schema would collapse the render-array nesting and cause a real regression. On one real site this accounts for 12 violations, all of them false positives on working configuration.

Steps to reproduce

  1. Add an eca_render_markup action (or any eca_render.action_base consumer) to an ECA model.
  2. Set Machine name to a nested value such as details][title, exactly as the field description instructs.
  3. Validate the resulting eca.eca.* config against its typed schema.

Result: The "details][title" machine name is not valid. Expected: No violation — this is the documented syntax.

Proposed resolution

Replace type: machine_name with a type that permits both the ][ nesting syntax and tokens. Either:

  1. type: string — simplest, and matches the field's actual contract, or
  2. a dedicated type with a Regex constraint allowing machine-name segments separated by ][, plus token syntax.

Option 2 preserves some validation value; option 1 is the minimal correct fix.

Note that the same review should cover eca_render.action_base.mode, which has a related problem — see the companion issue about the _eca_token sentinel being omitted from Choice constraints.

Remaining tasks

  • Choose a replacement type
  • Update eca_render.schema.yml
  • Add test coverage for a nested ][ machine name and for a tokenized value

User interface changes

None.

Data model changes

None.

Environment: ECA 3.1.5, Drupal 11.

AI-Generated: Yes (Used OpenCode to analyze typed-config validation output on a production site, trace the contradiction between the schema type and the plugin's documented contract, and draft this report. All references were verified against the installed code.)