Workflows submit job's "Build already submitted" pre-check validates against the ASC connection app, not the submit profile's ascAppId

[Willive]

Build/Submit details page URL

None included — happy to share workflow run IDs and the project slug privately with Expo staff.

Summary

In a project with multiple iOS apps (dev/qa/prod App Store Connect apps selected via different submit profiles' ascAppId), the EAS Workflows submit job runs a server-side duplicate check that appears to consult the project's App Store Connect connection app (the one configured in project settings for app_store_connect triggers) instead of the app the submission actually targets. The connection only allows one app per project, so every other app's submissions get validated against the wrong build history.

Managed or bare?

Managed

Environment

eas-cli 21.0.1 (dispatch + manual submits), Expo SDK 56. The failing check is server-side in Workflows submit jobs, not in the CLI.

Error output

upload jobs fail in under a second, before any submission entity is created, with:

Build already submitted — App Store Connect already has iOS version 1.0.0 (N). Run a new iOS build and re-run the workflow.

Reproducible demo or steps to reproduce from a blank project

1. One EAS project, three ASC apps via submit profiles. The prod ASC app is a legacy record with years of TestFlight history (its old 1.0.0 train contains builds 1–27). Dev/qa apps are newer with fewer builds.
2. Connect the ASC integration (project settings) to the prod app. Workflow submit jobs for the dev/qa apps immediately start failing with the error above — exactly when the (version, buildNumber) matches a build in the connected app's history. Numbers outside that history pass.
3. The flagged binaries are not duplicates: submitting the same build IDs via eas submit -p ios --profile <x> --id <build_id> (which skips this pre-check) uploads successfully — Apple accepts them into the correct target app.
4. Disconnecting the ASC connection makes the pre-check disappear entirely: the same workflow/profile proceeds to a real Transporter upload.

Expected behavior

The duplicate pre-check should resolve the ASC app the same way the submission itself does (the submit profile's ascAppId), not from the project-level connection.