Skip to content

Conversation

@dheerajturaga
Copy link
Member

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
image

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.

Can you help me which properties you were setting to make this working with an external nginx? I attempted to fix but got this:

Image

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" "-"

@dheerajturaga
Copy link
Member Author

My usual settings in prod are:

AIRFLOW__API__BASE_URL=https://my_company.com/airflow/
AIRFLOW__CORE__EXECUTION_API_SERVER_URL=https://my_company.com/airflow/execution/
AIRFLOW__EDGE__API_URL=https://my_company.com/airflow/edge_worker/v1/rpcapi

But Im not sucessfull in getting the Edge worker/Jobs page opened

@dheerajturaga
Copy link
Member Author

dheerajturaga commented Oct 2, 2025

@jscheffl I fixed this.

edge jobs nginx edge jobs nginx 2 image

Configuration used to launch nginx:

FROM nginx:alpine
COPY nginx.conf /etc/nginx/nginx.conf
EXPOSE 8080
events {
    worker_connections 1024;
}

http {
    server {
        listen 8080;
        server_name <hostname>;

        location /airflow {
            proxy_pass http://<localhost>:28080;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

Launch nginx after you have started up breeze with edge executor

docker build -f Dockerfile.nginx -t airflow-nginx . && docker run -d -p 8080:8080 --name airflow-nginx airflow-nginx

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

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.

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

@dheerajturaga dheerajturaga force-pushed the bugfix/edge-respect-base-url branch from cef452e to 3e01d0a Compare October 8, 2025 05:44
dheerajturaga and others added 4 commits October 8, 2025 09:02
  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>
@dheerajturaga dheerajturaga force-pushed the bugfix/edge-respect-base-url branch from 3e01d0a to e2e0f96 Compare October 8, 2025 14:02
@dheerajturaga
Copy link
Member Author

@jscheffl ongoing static check issue on main?

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! Fail in CI of static check is unrelated, therefore merging.

@jscheffl jscheffl merged commit 44381b6 into apache:main Oct 8, 2025
73 of 74 checks passed
abdulrahman305 bot pushed a commit to abdulrahman305/airflow that referenced this pull request Oct 9, 2025
…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>
abdulrahman305 bot pushed a commit to abdulrahman305/airflow that referenced this pull request Oct 10, 2025
…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>
abdulrahman305 bot pushed a commit to abdulrahman305/airflow that referenced this pull request Oct 11, 2025
…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>
abdulrahman305 bot pushed a commit to abdulrahman305/airflow that referenced this pull request Oct 12, 2025
…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>
dabla pushed a commit to dabla/airflow that referenced this pull request Oct 12, 2025
…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>
abdulrahman305 bot pushed a commit to abdulrahman305/airflow that referenced this pull request Oct 14, 2025
…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>
abdulrahman305 bot pushed a commit to abdulrahman305/airflow that referenced this pull request Oct 15, 2025
…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>
abdulrahman305 bot pushed a commit to abdulrahman305/airflow that referenced this pull request Oct 17, 2025
…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>
abdulrahman305 bot pushed a commit to abdulrahman305/airflow that referenced this pull request Oct 19, 2025
…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>
TyrellHaywood pushed a commit to TyrellHaywood/airflow that referenced this pull request Oct 22, 2025
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants