Fix task state store Execution API rejecting keys that contain slashes

[takayoshi-makabe]

Keys containing / (e.g. "spark/job_id") silently fail with 404 when accessed through the Execution API used by running tasks. The routes were defined with {key} instead of {key:path}, so FastAPI treated the slash as a path separator and could not match the route.

The Public API (used by UI/external clients), defined in airflow-core/src/airflow/api_fastapi/core_api/routes/public/task_state_store.py, already uses /{key:path} and is correct. This PR aligns the Execution API (airflow-core/src/airflow/api_fastapi/execution_api/routes/task_state_store.py) with that existing pattern.

A task managing multiple external jobs may naturally use slash-namespaced keys such as "spark/job_id" or "bigquery/status" to group related state — these silently returned 404 before this fix.

---

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

• Yes (please specify the tool below)

Claude Code

---

• 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.

[SameerMesiah97]

Looks good but CI needs to be triggered.

[ashb]

Should we accept path, or should we make the client url encode the key it sends? (Or both?)

[takayoshi-makabe]

@ashb
{key:path} seems like the right call here — the Public API already uses the same pattern, which keeps the two APIs consistent.

Client-side encoding could also be a good idea for added safety, but I think that can be treated as a separate concern.

[amoghrajesh]

@ashb I think both is a good idea. {key:path} on the server is the right defensive fix in any case, it matches what the core API already does and handles clients that do not encode - task sdk might not be the only client in the future.

@takayoshi-makabe Worth including in this PR since it's the same root cause.

[amoghrajesh]

@takayoshi-makabe changes look fine, can you handle client side encoding too? I will approve once thats done

[takayoshi-makabe]

@amoghrajesh @ashb

I added the client-side processing based on the code below.

• https://github.com/apache/airflow/blob/main/task-sdk/src/airflow/sdk/api/client.py#L992
• https://github.com/apache/airflow/blob/main/task-sdk/tests/task_sdk/api/test_client.py#L1740-L1769

commit: 2efa57a

[amoghrajesh]

Please update the tests as suggested.

[takayoshi-makabe]

@amoghrajesh
I have simplified the test. Could you please review it again?

[takayoshi-makabe]

@amoghrajesh Following up — addressed the test feedback on 2026-07-01, CI's green. Could you take another look when you have a chance?

[vatsrahul1001]

LGTM! Good to merge post review from code owners(@ashb @amoghrajesh @kaxil )

[github-actions]

Backport successfully created: v3-3-test

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
✅	v3-3-test