Rename task_store/asset_store to task_state_store/asset_state_store

[amoghrajesh]

---

Was generative AI tooling used to co-author this PR?

• Yes: claude sonnet 4.6

What

Renames task_store / asset_store to task_state_store / asset_state_store across the codebase. This is a purely mechanical rename, no logic, behaviour, or API contract changes.

Why

@ashb flagged the name AssetStore as a significant naming issue: it implies storing actual asset data (potentially GBs of files/objects), whereas these stores hold lightweight state metadata such as job IDs, watermarks, cursors, coordination tokens. The suffix StateStore makes the intent unambiguous.

Proposed change

Rename everything to TaskStateStore / AssetStateStore to make the intent clear. Scope of the rename:

• Models: TaskStoreModel -> TaskStateStoreModel, AssetStoreModel → AssetStateStoreModel
• DB cleanup service: MetastoreStoreBackend -> MetastoreStateStoreBackend
• Execution API: datamodels, route handlers, Cadwyn version schemas
• Core API: datamodels, route handlers, OpenAPI spec — URL path /store -> /state-store
• CLI: cleanup-task-store -> cleanup-task-state-store
• Task SDK: TaskStateStoreOperations, AssetStateStoreOperations, context keys task_state_store / asset_state_store, comms models
• UI: page components, generated OpenAPI client, i18n strings
• Docs: all RST files and toctree entries
• Tests: all affected test files and fixtures

Note: Execution API URL paths /store/ti and /store/asset are intentionally unchanged — workers already use them and changing them would require a versioned migration for no benefit.

Testing

Most of the testing here is for sanity purpose

1. DB sanity

2. Example dags run fine

3. UI renders well

(Since these use public APIs, we should be good)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[ashb]

I have only skimmed and spot checked this, so there is a change that we've picked up something unexpected in (what I assume was) the find+replace op.

[vincbeck]

Partially went through the code but I agree with the intent/change

[amoghrajesh]

The failures are unrelated, rebasing it now

[jscheffl]

"mega rename" sounds cool - and it is! LGTM so that we have a better naming in 3.3.0!

[dheerajturaga]

LGTM

[amoghrajesh]

Thanks for reviews all, merging this one now.

[github-actions]

Backport failed to create: airflow-ctl/v0-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	airflow-ctl/v0-1-test

You can attempt to backport this manually by running:

cherry_picker 74a52cf airflow-ctl/v0-1-test

This should apply the commit to the airflow-ctl/v0-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[jscheffl]

@amoghrajesh Noticed that my German translation catch-up now had new gaps as you renamed the new language keys. I reworked my PR (#68356) but I assume a lot of other parallel running translation PRs were outdated on the new keys due to the late change.

Does it make sense to bulk-rename already existing translations on main or do the translations need to change in your view adjusting to new key?