Machine-name columns that lead twenty-seven index positions are stored as if they could hold any character

Five columns hold a machine name this module produces itself, and every one of them is declared as if it could hold any Unicode character. Between them they sit in twenty-seven index positions across seven tables.

A varchar column carries a character set. On disk that costs nothing: a varchar stores the bytes it uses, in the table and in the index alike, because InnoDB writes a B-tree record with the actual bytes rather than the reserved width. What the declaration does decide is InnoDB's 3072-byte index key limit, which is computed from maximum widths, and the cost of every comparison, since ascii_general_ci is a simpler collation than utf8mb4_0900_ai_ci.

The columns

• state, in fourteen index positions on orchestra_token, orchestra_incident, orchestra_instance and orchestra_work_item. Every value is an interface constant: TokenInterface::STATE_*, IncidentInterface::STATE_*, ProcessInstanceInterface::STATE_*, WorkItemInterface::STATE_*. All fourteen StateTransitions::claimState() call sites name one, as do the entities' own setState() methods.
• tenant, in ten index positions across those four tables and orchestra_delegation. TenantField::getDefinition() describes it as the "Machine name of the tenant (realm) this row belongs to" and defaults it from the tenant context, which answers with a config entity id.
• definition on orchestra_instance, in orchestra_instance__definition_state_changed: "Machine name of the workflow".
• workflow on orchestra_workflow_version, in orchestra_workflow_version__workflow: "Machine name of the workflow this snapshot belongs to".
• entity_type_id on orchestra_attachment, in orchestra_attachment__target: an entity type ID, which core constrains.

These are all base fields of core's string type, so the change is a storage setting on each definition. That setting is honoured by string and string_long only; a list_string field ignores it, which is worth saying because it is the reason this list is not longer.

What is deliberately left alone

An ASCII column answers a value it cannot hold with a failed write, so the line is drawn by who produces the value rather than by what the value usually looks like. On the near side of it every value is a constant, a config entity id or an entity type ID, so a refused write cannot arise.

correlation_key and idempotency_key stay as they are: both are the caller's own words by definition, and a caller correlating by a business reference can hand over one that carries an accent. caller and origin are the same shape. name on orchestra_variable, node_id on orchestra_token, status on orchestra_instance and attachment_key on orchestra_attachment are named by whoever authored the workflow, and this issue does not assume what a modeler may type.

Upgrading

The narrower columns reach a site installing orchestra now. An existing site keeps what it has: changing a populated column is a separate question and is not attempted here.

AI-Generated: Yes (Claude Code was used to help draft this issue summary. The columns, their descriptions and the index definitions named here were read out of the storage schema handlers in src/, and the state call sites were counted in the source.)