Skip to content

Force the definition of execution_api_server_url based on api_url #52184

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

bdsoha
Copy link
Contributor

@bdsoha bdsoha commented Jun 24, 2025

Force the definition of execution_api_server_url based on api_url

This change ensures that the execution_api_server_url is automatically derived from api_url when not explicitly set. It supports compatibility with both Airflow 2 (internal API) and Airflow 3+ (execution API) without requiring implicit configuration.

Related: #52082


^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

@boring-cyborg boring-cyborg bot added area:providers provider:edge Edge Executor / Worker (AIP-69) labels Jun 24, 2025
@bdsoha bdsoha marked this pull request as ready for review June 24, 2025 18:46
@bdsoha bdsoha requested a review from jscheffl as a code owner June 24, 2025 18:46
@bdsoha
Copy link
Contributor Author

bdsoha commented Jun 24, 2025

The Tests AMD / CI image checks / MyPy checks (mypy-providers) (pull_request) is failure has nothing to do with this PR.

Copy link
Contributor

@jscheffl jscheffl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. Code looks good but in details it fails in "complexity" in which order the modules are loaded. I assume you rather need to set config in a try/catch not via if.

@bdsoha
Copy link
Contributor Author

bdsoha commented Jun 25, 2025

Thanks for the PR. Code looks good but in details it fails in "complexity" in which order the modules are loaded. I assume you rather need to set config in a try/catch not via if.

I'm not sure an if statement would help in this case, since all configuration values from provider.yaml are loaded via the @providers_configuration_loaded decorator, and core.execution_api_server_url isn't among them.

That’s why edge.api_url doesn’t fail here:

api_url = conf.get("edge", "api_url")
if not api_url:
raise SystemExit("Error: API URL is not configured, please correct configuration.")

There’s also a scenario where the user explicitly sets core.execution_api_server_url, but we override it early on in force_use_internal_api_on_edge_worker, before it’s even evaluated.

So in my opinion, this comes down to an implementation decision:
Do we really need to support both core.execution_api_server_url and edge.api_url in this provider, or can we simplify by assuming only edge.api_url will be used consistently?

@bdsoha
Copy link
Contributor Author

bdsoha commented Jun 25, 2025

@jscheffl Another alternative would be to insert the logic in worker.py directly.

def _launch_job_af3(self, edge_job: EdgeJobFetched) -> tuple[Process, Path]:

@jscheffl
Copy link
Contributor

@jscheffl Another alternative would be to insert the logic in worker.py directly.

def _launch_job_af3(self, edge_job: EdgeJobFetched) -> tuple[Process, Path]:

Yeah you are right. Implementation decision. Such hard thoughts needed. I agree the chicken egg is existing.

I assume there will be cases in the future where you might want to separate API server from task SDK API. Therefore I always kept it separate. The edge.api_url is for the provider just to to distribute the job and the core.execution_api_server_url is used by the task runner from task SDK. I would prefer to keep it separate for the moment.

Actually the idea to inject in _launch_job_af3() sounds liek a very good idea because (1) then it is just filling the gap on the point where needed (and not global) as well as removes the config loading problem at time of bootstrap!

@bdsoha
Copy link
Contributor Author

bdsoha commented Jun 29, 2025

@jscheffl I moved the implementation code to worker.py and added some tests.

@jscheffl jscheffl marked this pull request as draft June 29, 2025 09:02
@jscheffl
Copy link
Contributor

As you made WIP commits, converting the PR to "Draft". Let me know if I should re-review.

@bdsoha bdsoha marked this pull request as ready for review June 29, 2025 09:03
@bdsoha
Copy link
Contributor Author

bdsoha commented Jun 29, 2025

Ready for review.

Copy link
Contributor

@jscheffl jscheffl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix!

@jscheffl jscheffl merged commit d47f87c into apache:main Jun 29, 2025
128 checks passed
@bdsoha bdsoha deleted the feature/edge-force-execution-api-server-url branch June 29, 2025 09:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:providers provider:edge Edge Executor / Worker (AIP-69)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants