-
Notifications
You must be signed in to change notification settings - Fork 16.3k
Fix Edge3 provider navigation with webserver base_url configuration #56189
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
Fix Edge3 provider navigation with webserver base_url configuration #56189
Conversation
providers/edge3/src/airflow/providers/edge3/plugins/edge_executor_plugin.py
Outdated
Show resolved
Hide resolved
jscheffl
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you help me which properties you were setting to make this working with an external nginx? I attempted to fix but got this:
I was setting export AIRFLOW__API__BASE_URL=/af and export AIRFLOW__EDGE__API_URL=http://localhost:8080/af/edge_worker/v1/rpcap and restarted edge worker and API server.
After this I created a nginx config like
server {
if ($http_referer ~ ^https?://localhost:9000/af/) {
rewrite ^ /af$uri;
}
location /af/ {
proxy_pass http://192.168.31.176:28080/;
}
}
and started a docker with docker run -p 9000:80 -v $home/Workspace/airflow_review/nginx.conf:/etc/nginx/nginx.conf:ro nginx
Was able to log and and browse in http://localhost:9000 but not having the edge plugin calls working. they responded generated requests on nginx with:
172.17.0.1 - - [29/Sep/2025:21:27:35 +0000] "GET /edge_worker/ui/worker HTTP/1.1" 404 22 "http://localhost:9000/af/plugin/edge_worker" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36" "-"
|
My usual settings in prod are: But Im not sucessfull in getting the Edge worker/Jobs page opened |
|
@jscheffl I fixed this.
Configuration used to launch nginx: FROM nginx:alpine
COPY nginx.conf /etc/nginx/nginx.conf
EXPOSE 8080Launch nginx after you have started up breeze with edge executor
Kill and re-launch the api-server and edge worker in breeze with the following settings export AIRFLOW__API__BASE_URL=http://localhost:8080/airflow/
export AIRFLOW__CORE__EXECUTION_API_SERVER_URL=http://localhost:8080/airflow/execution/
export AIRFLOW__EDGE__API_URL=http://localhost:8080/airflow/edge_worker/v1/rpcapi |
jscheffl
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Just like a mini-nit. then I think we can merge.
Sorry took a moment until I had fiddled around making an nginx instance really working
cef452e to
3e01d0a
Compare
The Edge3 provider's BrowserRouter was not respecting the Airflow
webserver.base_url configuration, causing navigation links to generate
absolute paths from root instead of properly prefixed paths. This
resulted in 404 errors when Airflow is deployed with a base URL prefix
(e.g., my_company.com/airflow).
**Problem:**
- Edge3 provider pages were navigating to /plugin/edge_worker instead
of /airflow/plugin/edge_worker
- This broke navigation in deployments where nginx redirects traffic
from my_company.com/airflow to localhost:8080
- The issue was in JobsPage.tsx:94 where RouterLink generated links
without the base URL prefix
…ration The Edge3 provider's frontend was not respecting Airflow's webserver base_url configuration, causing API calls to fail when the webserver was configured with a subpath (e.g., localhost:8080/airflow). The OpenAPI-generated client was using an empty BASE configuration, resulting in API calls to /edge_worker/ui/jobs instead of /airflow/edge_worker/ui/jobs when base_url was set. This fix initializes OpenAPI.BASE from the HTML <base> tag, following the same pattern used in Airflow core, ensuring all API calls are correctly prefixed with the configured base URL path
…tor_plugin.py Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>
3e01d0a to
e2e0f96
Compare
|
@jscheffl ongoing static check issue on main? |
jscheffl
left a comment
There was a problem hiding this 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! Fail in CI of static check is unrelated, therefore merging.
…pache#56189) * Fix Edge3 provider navigation with webserver base_url configuration The Edge3 provider's BrowserRouter was not respecting the Airflow webserver.base_url configuration, causing navigation links to generate absolute paths from root instead of properly prefixed paths. This resulted in 404 errors when Airflow is deployed with a base URL prefix (e.g., my_company.com/airflow). **Problem:** - Edge3 provider pages were navigating to /plugin/edge_worker instead of /airflow/plugin/edge_worker - This broke navigation in deployments where nginx redirects traffic from my_company.com/airflow to localhost:8080 - The issue was in JobsPage.tsx:94 where RouterLink generated links without the base URL prefix * Fix: Added _get_base_url_path() helper function and updated all URLs to use it * Fix Edge3 provider frontend API calls with webserver base_url configuration The Edge3 provider's frontend was not respecting Airflow's webserver base_url configuration, causing API calls to fail when the webserver was configured with a subpath (e.g., localhost:8080/airflow). The OpenAPI-generated client was using an empty BASE configuration, resulting in API calls to /edge_worker/ui/jobs instead of /airflow/edge_worker/ui/jobs when base_url was set. This fix initializes OpenAPI.BASE from the HTML <base> tag, following the same pattern used in Airflow core, ensuring all API calls are correctly prefixed with the configured base URL path * Update providers/edge3/src/airflow/providers/edge3/plugins/edge_executor_plugin.py Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com> --------- Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>
…pache#56189) * Fix Edge3 provider navigation with webserver base_url configuration The Edge3 provider's BrowserRouter was not respecting the Airflow webserver.base_url configuration, causing navigation links to generate absolute paths from root instead of properly prefixed paths. This resulted in 404 errors when Airflow is deployed with a base URL prefix (e.g., my_company.com/airflow). **Problem:** - Edge3 provider pages were navigating to /plugin/edge_worker instead of /airflow/plugin/edge_worker - This broke navigation in deployments where nginx redirects traffic from my_company.com/airflow to localhost:8080 - The issue was in JobsPage.tsx:94 where RouterLink generated links without the base URL prefix * Fix: Added _get_base_url_path() helper function and updated all URLs to use it * Fix Edge3 provider frontend API calls with webserver base_url configuration The Edge3 provider's frontend was not respecting Airflow's webserver base_url configuration, causing API calls to fail when the webserver was configured with a subpath (e.g., localhost:8080/airflow). The OpenAPI-generated client was using an empty BASE configuration, resulting in API calls to /edge_worker/ui/jobs instead of /airflow/edge_worker/ui/jobs when base_url was set. This fix initializes OpenAPI.BASE from the HTML <base> tag, following the same pattern used in Airflow core, ensuring all API calls are correctly prefixed with the configured base URL path * Update providers/edge3/src/airflow/providers/edge3/plugins/edge_executor_plugin.py Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com> --------- Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>
…pache#56189) * Fix Edge3 provider navigation with webserver base_url configuration The Edge3 provider's BrowserRouter was not respecting the Airflow webserver.base_url configuration, causing navigation links to generate absolute paths from root instead of properly prefixed paths. This resulted in 404 errors when Airflow is deployed with a base URL prefix (e.g., my_company.com/airflow). **Problem:** - Edge3 provider pages were navigating to /plugin/edge_worker instead of /airflow/plugin/edge_worker - This broke navigation in deployments where nginx redirects traffic from my_company.com/airflow to localhost:8080 - The issue was in JobsPage.tsx:94 where RouterLink generated links without the base URL prefix * Fix: Added _get_base_url_path() helper function and updated all URLs to use it * Fix Edge3 provider frontend API calls with webserver base_url configuration The Edge3 provider's frontend was not respecting Airflow's webserver base_url configuration, causing API calls to fail when the webserver was configured with a subpath (e.g., localhost:8080/airflow). The OpenAPI-generated client was using an empty BASE configuration, resulting in API calls to /edge_worker/ui/jobs instead of /airflow/edge_worker/ui/jobs when base_url was set. This fix initializes OpenAPI.BASE from the HTML <base> tag, following the same pattern used in Airflow core, ensuring all API calls are correctly prefixed with the configured base URL path * Update providers/edge3/src/airflow/providers/edge3/plugins/edge_executor_plugin.py Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com> --------- Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>
…pache#56189) * Fix Edge3 provider navigation with webserver base_url configuration The Edge3 provider's BrowserRouter was not respecting the Airflow webserver.base_url configuration, causing navigation links to generate absolute paths from root instead of properly prefixed paths. This resulted in 404 errors when Airflow is deployed with a base URL prefix (e.g., my_company.com/airflow). **Problem:** - Edge3 provider pages were navigating to /plugin/edge_worker instead of /airflow/plugin/edge_worker - This broke navigation in deployments where nginx redirects traffic from my_company.com/airflow to localhost:8080 - The issue was in JobsPage.tsx:94 where RouterLink generated links without the base URL prefix * Fix: Added _get_base_url_path() helper function and updated all URLs to use it * Fix Edge3 provider frontend API calls with webserver base_url configuration The Edge3 provider's frontend was not respecting Airflow's webserver base_url configuration, causing API calls to fail when the webserver was configured with a subpath (e.g., localhost:8080/airflow). The OpenAPI-generated client was using an empty BASE configuration, resulting in API calls to /edge_worker/ui/jobs instead of /airflow/edge_worker/ui/jobs when base_url was set. This fix initializes OpenAPI.BASE from the HTML <base> tag, following the same pattern used in Airflow core, ensuring all API calls are correctly prefixed with the configured base URL path * Update providers/edge3/src/airflow/providers/edge3/plugins/edge_executor_plugin.py Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com> --------- Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>
…pache#56189) * Fix Edge3 provider navigation with webserver base_url configuration The Edge3 provider's BrowserRouter was not respecting the Airflow webserver.base_url configuration, causing navigation links to generate absolute paths from root instead of properly prefixed paths. This resulted in 404 errors when Airflow is deployed with a base URL prefix (e.g., my_company.com/airflow). **Problem:** - Edge3 provider pages were navigating to /plugin/edge_worker instead of /airflow/plugin/edge_worker - This broke navigation in deployments where nginx redirects traffic from my_company.com/airflow to localhost:8080 - The issue was in JobsPage.tsx:94 where RouterLink generated links without the base URL prefix * Fix: Added _get_base_url_path() helper function and updated all URLs to use it * Fix Edge3 provider frontend API calls with webserver base_url configuration The Edge3 provider's frontend was not respecting Airflow's webserver base_url configuration, causing API calls to fail when the webserver was configured with a subpath (e.g., localhost:8080/airflow). The OpenAPI-generated client was using an empty BASE configuration, resulting in API calls to /edge_worker/ui/jobs instead of /airflow/edge_worker/ui/jobs when base_url was set. This fix initializes OpenAPI.BASE from the HTML <base> tag, following the same pattern used in Airflow core, ensuring all API calls are correctly prefixed with the configured base URL path * Update providers/edge3/src/airflow/providers/edge3/plugins/edge_executor_plugin.py Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com> --------- Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>
…pache#56189) * Fix Edge3 provider navigation with webserver base_url configuration The Edge3 provider's BrowserRouter was not respecting the Airflow webserver.base_url configuration, causing navigation links to generate absolute paths from root instead of properly prefixed paths. This resulted in 404 errors when Airflow is deployed with a base URL prefix (e.g., my_company.com/airflow). **Problem:** - Edge3 provider pages were navigating to /plugin/edge_worker instead of /airflow/plugin/edge_worker - This broke navigation in deployments where nginx redirects traffic from my_company.com/airflow to localhost:8080 - The issue was in JobsPage.tsx:94 where RouterLink generated links without the base URL prefix * Fix: Added _get_base_url_path() helper function and updated all URLs to use it * Fix Edge3 provider frontend API calls with webserver base_url configuration The Edge3 provider's frontend was not respecting Airflow's webserver base_url configuration, causing API calls to fail when the webserver was configured with a subpath (e.g., localhost:8080/airflow). The OpenAPI-generated client was using an empty BASE configuration, resulting in API calls to /edge_worker/ui/jobs instead of /airflow/edge_worker/ui/jobs when base_url was set. This fix initializes OpenAPI.BASE from the HTML <base> tag, following the same pattern used in Airflow core, ensuring all API calls are correctly prefixed with the configured base URL path * Update providers/edge3/src/airflow/providers/edge3/plugins/edge_executor_plugin.py Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com> --------- Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>
…pache#56189) * Fix Edge3 provider navigation with webserver base_url configuration The Edge3 provider's BrowserRouter was not respecting the Airflow webserver.base_url configuration, causing navigation links to generate absolute paths from root instead of properly prefixed paths. This resulted in 404 errors when Airflow is deployed with a base URL prefix (e.g., my_company.com/airflow). **Problem:** - Edge3 provider pages were navigating to /plugin/edge_worker instead of /airflow/plugin/edge_worker - This broke navigation in deployments where nginx redirects traffic from my_company.com/airflow to localhost:8080 - The issue was in JobsPage.tsx:94 where RouterLink generated links without the base URL prefix * Fix: Added _get_base_url_path() helper function and updated all URLs to use it * Fix Edge3 provider frontend API calls with webserver base_url configuration The Edge3 provider's frontend was not respecting Airflow's webserver base_url configuration, causing API calls to fail when the webserver was configured with a subpath (e.g., localhost:8080/airflow). The OpenAPI-generated client was using an empty BASE configuration, resulting in API calls to /edge_worker/ui/jobs instead of /airflow/edge_worker/ui/jobs when base_url was set. This fix initializes OpenAPI.BASE from the HTML <base> tag, following the same pattern used in Airflow core, ensuring all API calls are correctly prefixed with the configured base URL path * Update providers/edge3/src/airflow/providers/edge3/plugins/edge_executor_plugin.py Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com> --------- Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>
…pache#56189) * Fix Edge3 provider navigation with webserver base_url configuration The Edge3 provider's BrowserRouter was not respecting the Airflow webserver.base_url configuration, causing navigation links to generate absolute paths from root instead of properly prefixed paths. This resulted in 404 errors when Airflow is deployed with a base URL prefix (e.g., my_company.com/airflow). **Problem:** - Edge3 provider pages were navigating to /plugin/edge_worker instead of /airflow/plugin/edge_worker - This broke navigation in deployments where nginx redirects traffic from my_company.com/airflow to localhost:8080 - The issue was in JobsPage.tsx:94 where RouterLink generated links without the base URL prefix * Fix: Added _get_base_url_path() helper function and updated all URLs to use it * Fix Edge3 provider frontend API calls with webserver base_url configuration The Edge3 provider's frontend was not respecting Airflow's webserver base_url configuration, causing API calls to fail when the webserver was configured with a subpath (e.g., localhost:8080/airflow). The OpenAPI-generated client was using an empty BASE configuration, resulting in API calls to /edge_worker/ui/jobs instead of /airflow/edge_worker/ui/jobs when base_url was set. This fix initializes OpenAPI.BASE from the HTML <base> tag, following the same pattern used in Airflow core, ensuring all API calls are correctly prefixed with the configured base URL path * Update providers/edge3/src/airflow/providers/edge3/plugins/edge_executor_plugin.py Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com> --------- Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>
…pache#56189) * Fix Edge3 provider navigation with webserver base_url configuration The Edge3 provider's BrowserRouter was not respecting the Airflow webserver.base_url configuration, causing navigation links to generate absolute paths from root instead of properly prefixed paths. This resulted in 404 errors when Airflow is deployed with a base URL prefix (e.g., my_company.com/airflow). **Problem:** - Edge3 provider pages were navigating to /plugin/edge_worker instead of /airflow/plugin/edge_worker - This broke navigation in deployments where nginx redirects traffic from my_company.com/airflow to localhost:8080 - The issue was in JobsPage.tsx:94 where RouterLink generated links without the base URL prefix * Fix: Added _get_base_url_path() helper function and updated all URLs to use it * Fix Edge3 provider frontend API calls with webserver base_url configuration The Edge3 provider's frontend was not respecting Airflow's webserver base_url configuration, causing API calls to fail when the webserver was configured with a subpath (e.g., localhost:8080/airflow). The OpenAPI-generated client was using an empty BASE configuration, resulting in API calls to /edge_worker/ui/jobs instead of /airflow/edge_worker/ui/jobs when base_url was set. This fix initializes OpenAPI.BASE from the HTML <base> tag, following the same pattern used in Airflow core, ensuring all API calls are correctly prefixed with the configured base URL path * Update providers/edge3/src/airflow/providers/edge3/plugins/edge_executor_plugin.py Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com> --------- Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>
…pache#56189) * Fix Edge3 provider navigation with webserver base_url configuration The Edge3 provider's BrowserRouter was not respecting the Airflow webserver.base_url configuration, causing navigation links to generate absolute paths from root instead of properly prefixed paths. This resulted in 404 errors when Airflow is deployed with a base URL prefix (e.g., my_company.com/airflow). **Problem:** - Edge3 provider pages were navigating to /plugin/edge_worker instead of /airflow/plugin/edge_worker - This broke navigation in deployments where nginx redirects traffic from my_company.com/airflow to localhost:8080 - The issue was in JobsPage.tsx:94 where RouterLink generated links without the base URL prefix * Fix: Added _get_base_url_path() helper function and updated all URLs to use it * Fix Edge3 provider frontend API calls with webserver base_url configuration The Edge3 provider's frontend was not respecting Airflow's webserver base_url configuration, causing API calls to fail when the webserver was configured with a subpath (e.g., localhost:8080/airflow). The OpenAPI-generated client was using an empty BASE configuration, resulting in API calls to /edge_worker/ui/jobs instead of /airflow/edge_worker/ui/jobs when base_url was set. This fix initializes OpenAPI.BASE from the HTML <base> tag, following the same pattern used in Airflow core, ensuring all API calls are correctly prefixed with the configured base URL path * Update providers/edge3/src/airflow/providers/edge3/plugins/edge_executor_plugin.py Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com> --------- Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>



The Edge3 provider's BrowserRouter was not respecting the Airflow
webserver.base_url configuration, causing navigation links to generate
absolute paths from root instead of properly prefixed paths. This
resulted in 404 errors when Airflow is deployed with a base URL prefix
(e.g., my_company.com/airflow).
Problem: