When creating a batch change with the server-side workflow, we initiate the batch change in a "draft" state with an empty batch spec. The empty batch spec is predominantly an internal concept because it will never be executed nor applied. However, it is currently surfaced in the UI wherever we list executions/specs:

It is rather bizarre and unexpected to show it here, because:

1. It will always remain in the "Processing" state, which makes it seem like something will happen with it
2. Its timer will keep counting up to infinity, because of 1.
3. It has no spec contents.
4. For a draft batch change, it will auto-open on the specs tab because it's the spec that's "currently applied"

We cannot overwrite the empty batch spec while a batch change is still a draft as the newer batch spec will not be applied yet.

I think we would be best to omit empty batch specs at the batch spec connection resolver layer, so that the following are true:

• If I have never touched the batch spec for a draft batch change, the connection should be empty.
• If I have modified the batch spec and previewed workspaces (thus saving my changes as a new unapplied batch spec), the connection should return that single batch spec.
• If none of the batch specs in the connection have been applied yet, the latest batch spec should auto-open on the specs tab instead.

There isn't presently an easy way from the DB to distinguish an empty batch spec from a non-empty one, but the most straightforward approach would probably be to match on any spec whose raw_spec only contains the name: field and nothing else. Alternatively, we could add a boolean column to index this instead and , but we'd need a migration to backfill existing batch specs.

Though less important, another success criterion is that empty batch specs should also be omitted from the admin executions view: