workflow:validate crashes with "Cannot read properties of undefined (reading 'const')" when the published schema has a job entry without properties.type

[BjornMelin]

Summary

eas workflow:validate fails for every workflow file with:

- Validating the workflow YAML file…
✖ Workflow configuration YAML is not valid.
Error: Cannot read properties of undefined (reading 'const')

The failure happens before any workflow is validated, so it is not caused by the workflow content. It reproduces on a workflow that a previous CLI release reported as valid.

Cause

eas workflow:validate fetches the published workflow schema from GET /v2/workflows/schema and then builds its job-type allowlist in build/commandUtils/workflow/validation.js:

function jobTypesFromWorkflowSchema(workflowJsonSchema) {
  return workflowJsonSchema?.properties?.jobs?.additionalProperties?.anyOf.map(
    (props) => props.properties.type.const,
  );
}

validateWorkflowJobTypes calls this before validateWorkflowStructure, so a TypeError here aborts validation entirely.

The published schema now also contains a catch-all job entry that has no properties.type (its shape is name/if/… plus additionalProperties, used for job types outside the named set). Reading props.properties.type.const on that entry throws the observed TypeError.

Entries 0-17 of anyOf all carry properties.type.const (build, custom, deploy, fingerprint, get-build, maestro-cloud, maestro, require-approval, apple-device-registration-request, submit, testflight, update, slack, doc, repack, github-comment, branch-delete, update-rollout); the additional entry does not.

Reproduction

Any project with a workflow file:

eas workflow:validate .eas/workflows/build-preview.yml --non-interactive

Checked versions: 22.6.0, 23.0.0, 24.0.0, 24.4.0, 24.8.0 (latest) — all contain the same expression and all fail.

Workaround

Point the validator at a copy of the schema without the catch-all entry, using the existing hook in fetchWorkflowSchemaAsync:

EXPO_TESTING_WORKFLOW_SCHEMA_PATH=/path/to/schema-without-catch-all.json \
  eas workflow:validate .eas/workflows/build-preview.yml --non-interactive

With that entry removed the same CLI reports the unmodified workflow as valid, so the workflow content itself is fine.

Suggested fix

Collect job types defensively, ignoring entries that do not declare one:

return (workflowJsonSchema?.properties?.jobs?.additionalProperties?.anyOf ?? [])
  .map((props) => props?.properties?.type?.const)
  .filter((type) => typeof type === 'string');

Ideally the catch-all entry would also be distinguishable without relying on its position in anyOf.

[JavanPoirier]

+1

[Abattisson]

+1

[danielhopkins]

We see the same crash in CI, from 2026-09-29. Some data that can help:

All recent versions fail. We tested 22.0.0, 23.0.0, 24.0.0, 24.4.0, 24.7.0 and 24.8.0 (latest). Each version has the same unguarded .map() and fetches the same schema, so pinning an older version does not help.

The workflow file is not the cause. Our workflow file did not change between the last passing run (2026-09-28) and the first failing run. The eas-cli version (24.8.0) did not change either.

A null-safe map fixes it. We ran the three client-side checks offline against the live schema with this change. Job types, structure and build profiles all pass:

function jobTypesFromWorkflowSchema(workflowJsonSchema) {
  return workflowJsonSchema?.properties?.jobs?.additionalProperties?.anyOf
    ?.map((props) => props?.properties?.type?.const)
    .filter((type) => type !== undefined);
}

A workaround for CI. The crash also prints Workflow configuration YAML is not valid, so a script that looks for that line reads the crash as a real rejection. We now check for Cannot read properties of undefined (reading 'const') first. If we find it, we write a warning and continue. eas workflow:run still validates the file on the server, so a file that is really invalid still fails there.