[Security Solution] Enforce sending the request to API even if offline, for air-gapped environment. by jkelas · Pull Request #220510 · elastic/kibana

jkelas · 2025-05-08T13:12:41Z

Resolves: #181808

Summary

I am fixing the issue of the Rules and Alerts tabs in Security, as well as the Fleet tab in Management, that gets stalled in air-gapped environment. I am doing so by enforcing the request to be sent to the API even when offline.

Historical context:

During investigation of the original issue #181808 I proved that Kibana doesn't try to reach to EPR in the air-gapped environment (that is, with the xpack.fleet.isAirGapped: true flag, and WIFI being turned ON). I commented this here and we closed the issue. However, @111andre111 reached out to us saying that this wasn't enough, as the real issue remains, that is, Kibana doesn't behave properly when:

xpack.fleet.isAirGapped flag is set to true
there is no Internet connection (WIFI off or cable physically disconnected)

That's why we reopened the ticket and I restarted the investigation.
My first observation was that when I turn off the WIFI, I cannot see requests to the API being sent in the Network tab in Dev Tools, most importantly to the _bootstrap endpoint at the first entrance to the Solution app, and other endpoints later. I searched that the browser discovers being offline and suppresses such calls. When WIFI is back ON, then the browser sends these requests. That was exactly what I saw in the Network tab.
I searched and found an option to force browser to always send the request, regardless of what it thinks about connectivity. Such option, networkMode: 'always', can be added to TanStackQuery client.

I started working on adding this option to occurences of useQuery and useMutation, and immediately sounded success, as the behavior was correct. However, @xcrzx rigthfully pointed out, that it would be much better to only add it to one place, that is the configuration of the QueryClient. I did it, and to my surprise, the problem returned.
I noticed that adding this option to the QueryClient in Fleet solved the problem in the Fleet tab immediately, but adding this option to the SecuritySolutionQueryClient does nothing, like it was completely ignored.
I searched different options and spent two more days debugging the problem, but then, when paired up again with Dmitrii, he found that the SecuritySolutionQueryClient is overshadowed by some other QueryClient present in the stack of components much below, the CasesContext. That discovery enabled me to add this new setting to the other QueryClient, and this fixes the issue. However, we think that it will be worth investigating why we need this second context, as the situation when one QueryClient overshadows another one, smells badly and may be a source of other issues as well (I will reach out to the team responsible for the CasesContext and ask if we can unify this somehow).

BEFORE

BEFORE.mov

AFTER

AFTER.mov

Checklist

Check the PR satisfies following conditions.

Reviewers should verify this PR satisfies this list as well.

Unit or functional tests were updated or added to match the most common scenarios
If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The release_note:breaking label should be applied in these situations.
Flaky Test Runner was used on any tests changed
The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines

elasticmachine · 2025-05-08T14:25:51Z

Pinging @elastic/security-detections-response (Team:Detections and Resp)

elasticmachine · 2025-05-08T14:25:52Z

Pinging @elastic/security-solution (Team: SecuritySolution)

elasticmachine · 2025-05-08T14:25:54Z

Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)

elasticmachine · 2025-05-08T18:05:05Z

Pinging @elastic/fleet (Team:Fleet)

nchaulet · 2025-05-09T18:05:24Z

x-pack/platform/plugins/shared/fleet/public/applications/fleet/app.tsx

 const FEEDBACK_URL = 'https://ela.st/fleet-feedback';

-const queryClient = new QueryClient();
+const queryClient = new QueryClient({


Nice finding! We have a second client in Fleet for the integration app, it probably should have the same treatment https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/fleet/public/applications/integrations/app.tsx#L49

@nchaulet I implemented your remark, please take a look

elasticmachine · 2025-06-10T10:04:55Z

💚 Build Succeeded

Buildkite Build
Commit: c30d480

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
`fleet`	1.8MB	1.8MB	+168.0B
`securitySolution`	9.3MB	9.3MB	+528.0B
total			+696.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
`cases`	134.1KB	134.1KB	+84.0B

History

💚 Build #305894 succeeded d727eb4
💛 Build #305677 was flaky 9a16698
💚 Build #304750 succeeded ed0f13d
💚 Build #304186 succeeded e7f8ae7
💔 Build #301940 failed 1371bdd
💔 Build #301243 failed 1371bdd

cc @jkelas

kibanamachine · 2025-06-10T10:15:09Z

Starting backport for target branches: 8.19, 9.0

https://github.com/elastic/kibana/actions/runs/15556799386

@111andre111

…e, for air-gapped environment. (elastic#220510) **Resolves: elastic#181808** ## Summary I am fixing the issue of the Rules and Alerts tabs in Security, as well as the Fleet tab in Management, that gets stalled in air-gapped environment. I am doing so by enforcing the request to be sent to the API even when offline. ### Historical context: During investigation of the original issue elastic#181808 I proved that Kibana doesn't try to reach to EPR in the air-gapped environment (that is, with the `xpack.fleet.isAirGapped: true` flag, and WIFI being turned ON). I commented this [here](elastic#181808 (comment)) and we closed the issue. However, @111andre111 reached out to us saying that this wasn't enough, as the real issue remains, that is, Kibana doesn't behave properly when: - `xpack.fleet.isAirGapped` flag is set to `true` - there is no Internet connection (WIFI off or cable physically disconnected) That's why we reopened the ticket and I restarted the investigation. My first observation was that when I turn off the WIFI, I cannot see requests to the API being sent in the Network tab in Dev Tools, most importantly to the `_bootstrap` endpoint at the first entrance to the Solution app, and other endpoints later. I searched that the browser discovers being offline and suppresses such calls. When WIFI is back ON, then the browser sends these requests. That was exactly what I saw in the Network tab. I searched and found an option to force browser to always send the request, regardless of what it thinks about connectivity. Such option, `networkMode: 'always'`, can be added to TanStackQuery client. I started working on adding this option to occurences of `useQuery` and `useMutation`, and immediately sounded success, as the behavior was correct. However, @xcrzx rigthfully pointed out, that it would be much better to only add it to one place, that is the configuration of the QueryClient. I did it, and to my surprise, the problem returned. I noticed that adding this option to the QueryClient in Fleet solved the problem in the Fleet tab immediately, but adding this option to the `SecuritySolutionQueryClient` does nothing, like it was completely ignored. I searched different options and spent two more days debugging the problem, but then, when paired up again with Dmitrii, he found that the `SecuritySolutionQueryClient` is overshadowed by some other QueryClient present in the stack of components much below, the `CasesContext`. That discovery enabled me to add this new setting to the other QueryClient, and this fixes the issue. However, we think that it will be worth investigating why we need this second context, as the situation when one QueryClient overshadows another one, smells badly and may be a source of other issues as well (I will reach out to the team responsible for the CasesContext and ask if we can unify this somehow). ## BEFORE https://github.com/user-attachments/assets/662dab73-b1bd-4d6b-9d15-c35efab679c6 ## AFTER https://github.com/user-attachments/assets/b905bde0-150d-478d-9734-9003fb5bcf66 ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 7ad35a4)

@111andre111

…e, for air-gapped environment. (elastic#220510) **Resolves: elastic#181808** ## Summary I am fixing the issue of the Rules and Alerts tabs in Security, as well as the Fleet tab in Management, that gets stalled in air-gapped environment. I am doing so by enforcing the request to be sent to the API even when offline. ### Historical context: During investigation of the original issue elastic#181808 I proved that Kibana doesn't try to reach to EPR in the air-gapped environment (that is, with the `xpack.fleet.isAirGapped: true` flag, and WIFI being turned ON). I commented this [here](elastic#181808 (comment)) and we closed the issue. However, @111andre111 reached out to us saying that this wasn't enough, as the real issue remains, that is, Kibana doesn't behave properly when: - `xpack.fleet.isAirGapped` flag is set to `true` - there is no Internet connection (WIFI off or cable physically disconnected) That's why we reopened the ticket and I restarted the investigation. My first observation was that when I turn off the WIFI, I cannot see requests to the API being sent in the Network tab in Dev Tools, most importantly to the `_bootstrap` endpoint at the first entrance to the Solution app, and other endpoints later. I searched that the browser discovers being offline and suppresses such calls. When WIFI is back ON, then the browser sends these requests. That was exactly what I saw in the Network tab. I searched and found an option to force browser to always send the request, regardless of what it thinks about connectivity. Such option, `networkMode: 'always'`, can be added to TanStackQuery client. I started working on adding this option to occurences of `useQuery` and `useMutation`, and immediately sounded success, as the behavior was correct. However, @xcrzx rigthfully pointed out, that it would be much better to only add it to one place, that is the configuration of the QueryClient. I did it, and to my surprise, the problem returned. I noticed that adding this option to the QueryClient in Fleet solved the problem in the Fleet tab immediately, but adding this option to the `SecuritySolutionQueryClient` does nothing, like it was completely ignored. I searched different options and spent two more days debugging the problem, but then, when paired up again with Dmitrii, he found that the `SecuritySolutionQueryClient` is overshadowed by some other QueryClient present in the stack of components much below, the `CasesContext`. That discovery enabled me to add this new setting to the other QueryClient, and this fixes the issue. However, we think that it will be worth investigating why we need this second context, as the situation when one QueryClient overshadows another one, smells badly and may be a source of other issues as well (I will reach out to the team responsible for the CasesContext and ask if we can unify this somehow). ## BEFORE https://github.com/user-attachments/assets/662dab73-b1bd-4d6b-9d15-c35efab679c6 ## AFTER https://github.com/user-attachments/assets/b905bde0-150d-478d-9734-9003fb5bcf66 ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 7ad35a4)

kibanamachine · 2025-06-10T10:21:54Z

💚 All backports created successfully

Status	Branch	Result
✅	8.19
✅	9.0

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

@111andre111

… offline, for air-gapped environment. (#220510) (#223204) # Backport This will backport the following commits from `main` to `8.19`: - [[Security Solution] Enforce sending the request to API even if offline, for air-gapped environment. (#220510)](#220510)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)  Co-authored-by: Jacek Kolezynski <jacek.kolezynski@elastic.co>

@111andre111

…offline, for air-gapped environment. (#220510) (#223205) # Backport This will backport the following commits from `main` to `9.0`: - [[Security Solution] Enforce sending the request to API even if offline, for air-gapped environment. (#220510)](#220510)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)  Co-authored-by: Jacek Kolezynski <jacek.kolezynski@elastic.co>

@111andre111

…e, for air-gapped environment. (elastic#220510) **Resolves: elastic#181808** ## Summary I am fixing the issue of the Rules and Alerts tabs in Security, as well as the Fleet tab in Management, that gets stalled in air-gapped environment. I am doing so by enforcing the request to be sent to the API even when offline. ### Historical context: During investigation of the original issue elastic#181808 I proved that Kibana doesn't try to reach to EPR in the air-gapped environment (that is, with the `xpack.fleet.isAirGapped: true` flag, and WIFI being turned ON). I commented this [here](elastic#181808 (comment)) and we closed the issue. However, @111andre111 reached out to us saying that this wasn't enough, as the real issue remains, that is, Kibana doesn't behave properly when: - `xpack.fleet.isAirGapped` flag is set to `true` - there is no Internet connection (WIFI off or cable physically disconnected) That's why we reopened the ticket and I restarted the investigation. My first observation was that when I turn off the WIFI, I cannot see requests to the API being sent in the Network tab in Dev Tools, most importantly to the `_bootstrap` endpoint at the first entrance to the Solution app, and other endpoints later. I searched that the browser discovers being offline and suppresses such calls. When WIFI is back ON, then the browser sends these requests. That was exactly what I saw in the Network tab. I searched and found an option to force browser to always send the request, regardless of what it thinks about connectivity. Such option, `networkMode: 'always'`, can be added to TanStackQuery client. I started working on adding this option to occurences of `useQuery` and `useMutation`, and immediately sounded success, as the behavior was correct. However, @xcrzx rigthfully pointed out, that it would be much better to only add it to one place, that is the configuration of the QueryClient. I did it, and to my surprise, the problem returned. I noticed that adding this option to the QueryClient in Fleet solved the problem in the Fleet tab immediately, but adding this option to the `SecuritySolutionQueryClient` does nothing, like it was completely ignored. I searched different options and spent two more days debugging the problem, but then, when paired up again with Dmitrii, he found that the `SecuritySolutionQueryClient` is overshadowed by some other QueryClient present in the stack of components much below, the `CasesContext`. That discovery enabled me to add this new setting to the other QueryClient, and this fixes the issue. However, we think that it will be worth investigating why we need this second context, as the situation when one QueryClient overshadows another one, smells badly and may be a source of other issues as well (I will reach out to the team responsible for the CasesContext and ask if we can unify this somehow). ## BEFORE https://github.com/user-attachments/assets/662dab73-b1bd-4d6b-9d15-c35efab679c6 ## AFTER https://github.com/user-attachments/assets/b905bde0-150d-478d-9734-9003fb5bcf66 ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

@111andre111

…e, for air-gapped environment. (elastic#220510) **Resolves: elastic#181808** ## Summary I am fixing the issue of the Rules and Alerts tabs in Security, as well as the Fleet tab in Management, that gets stalled in air-gapped environment. I am doing so by enforcing the request to be sent to the API even when offline. ### Historical context: During investigation of the original issue elastic#181808 I proved that Kibana doesn't try to reach to EPR in the air-gapped environment (that is, with the `xpack.fleet.isAirGapped: true` flag, and WIFI being turned ON). I commented this [here](elastic#181808 (comment)) and we closed the issue. However, @111andre111 reached out to us saying that this wasn't enough, as the real issue remains, that is, Kibana doesn't behave properly when: - `xpack.fleet.isAirGapped` flag is set to `true` - there is no Internet connection (WIFI off or cable physically disconnected) That's why we reopened the ticket and I restarted the investigation. My first observation was that when I turn off the WIFI, I cannot see requests to the API being sent in the Network tab in Dev Tools, most importantly to the `_bootstrap` endpoint at the first entrance to the Solution app, and other endpoints later. I searched that the browser discovers being offline and suppresses such calls. When WIFI is back ON, then the browser sends these requests. That was exactly what I saw in the Network tab. I searched and found an option to force browser to always send the request, regardless of what it thinks about connectivity. Such option, `networkMode: 'always'`, can be added to TanStackQuery client. I started working on adding this option to occurences of `useQuery` and `useMutation`, and immediately sounded success, as the behavior was correct. However, @xcrzx rigthfully pointed out, that it would be much better to only add it to one place, that is the configuration of the QueryClient. I did it, and to my surprise, the problem returned. I noticed that adding this option to the QueryClient in Fleet solved the problem in the Fleet tab immediately, but adding this option to the `SecuritySolutionQueryClient` does nothing, like it was completely ignored. I searched different options and spent two more days debugging the problem, but then, when paired up again with Dmitrii, he found that the `SecuritySolutionQueryClient` is overshadowed by some other QueryClient present in the stack of components much below, the `CasesContext`. That discovery enabled me to add this new setting to the other QueryClient, and this fixes the issue. However, we think that it will be worth investigating why we need this second context, as the situation when one QueryClient overshadows another one, smells badly and may be a source of other issues as well (I will reach out to the team responsible for the CasesContext and ask if we can unify this somehow). ## BEFORE https://github.com/user-attachments/assets/662dab73-b1bd-4d6b-9d15-c35efab679c6 ## AFTER https://github.com/user-attachments/assets/b905bde0-150d-478d-9734-9003fb5bcf66 ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

@111andre111

…e, for air-gapped environment. (elastic#220510) **Resolves: elastic#181808** ## Summary I am fixing the issue of the Rules and Alerts tabs in Security, as well as the Fleet tab in Management, that gets stalled in air-gapped environment. I am doing so by enforcing the request to be sent to the API even when offline. ### Historical context: During investigation of the original issue elastic#181808 I proved that Kibana doesn't try to reach to EPR in the air-gapped environment (that is, with the `xpack.fleet.isAirGapped: true` flag, and WIFI being turned ON). I commented this [here](elastic#181808 (comment)) and we closed the issue. However, @111andre111 reached out to us saying that this wasn't enough, as the real issue remains, that is, Kibana doesn't behave properly when: - `xpack.fleet.isAirGapped` flag is set to `true` - there is no Internet connection (WIFI off or cable physically disconnected) That's why we reopened the ticket and I restarted the investigation. My first observation was that when I turn off the WIFI, I cannot see requests to the API being sent in the Network tab in Dev Tools, most importantly to the `_bootstrap` endpoint at the first entrance to the Solution app, and other endpoints later. I searched that the browser discovers being offline and suppresses such calls. When WIFI is back ON, then the browser sends these requests. That was exactly what I saw in the Network tab. I searched and found an option to force browser to always send the request, regardless of what it thinks about connectivity. Such option, `networkMode: 'always'`, can be added to TanStackQuery client. I started working on adding this option to occurences of `useQuery` and `useMutation`, and immediately sounded success, as the behavior was correct. However, @xcrzx rigthfully pointed out, that it would be much better to only add it to one place, that is the configuration of the QueryClient. I did it, and to my surprise, the problem returned. I noticed that adding this option to the QueryClient in Fleet solved the problem in the Fleet tab immediately, but adding this option to the `SecuritySolutionQueryClient` does nothing, like it was completely ignored. I searched different options and spent two more days debugging the problem, but then, when paired up again with Dmitrii, he found that the `SecuritySolutionQueryClient` is overshadowed by some other QueryClient present in the stack of components much below, the `CasesContext`. That discovery enabled me to add this new setting to the other QueryClient, and this fixes the issue. However, we think that it will be worth investigating why we need this second context, as the situation when one QueryClient overshadows another one, smells badly and may be a source of other issues as well (I will reach out to the team responsible for the CasesContext and ask if we can unify this somehow). ## BEFORE https://github.com/user-attachments/assets/662dab73-b1bd-4d6b-9d15-c35efab679c6 ## AFTER https://github.com/user-attachments/assets/b905bde0-150d-478d-9734-9003fb5bcf66 ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

banderror · 2025-06-24T09:41:50Z

@jkelas Let's backport it to 8.18 so that the fix can be released in v8.18.4 as well.

jkelas · 2025-06-24T15:17:16Z

💚 All backports created successfully

Status	Branch	Result
✅	8.18

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

@111andre111

…e, for air-gapped environment. (elastic#220510) **Resolves: elastic#181808** ## Summary I am fixing the issue of the Rules and Alerts tabs in Security, as well as the Fleet tab in Management, that gets stalled in air-gapped environment. I am doing so by enforcing the request to be sent to the API even when offline. ### Historical context: During investigation of the original issue elastic#181808 I proved that Kibana doesn't try to reach to EPR in the air-gapped environment (that is, with the `xpack.fleet.isAirGapped: true` flag, and WIFI being turned ON). I commented this [here](elastic#181808 (comment)) and we closed the issue. However, @111andre111 reached out to us saying that this wasn't enough, as the real issue remains, that is, Kibana doesn't behave properly when: - `xpack.fleet.isAirGapped` flag is set to `true` - there is no Internet connection (WIFI off or cable physically disconnected) That's why we reopened the ticket and I restarted the investigation. My first observation was that when I turn off the WIFI, I cannot see requests to the API being sent in the Network tab in Dev Tools, most importantly to the `_bootstrap` endpoint at the first entrance to the Solution app, and other endpoints later. I searched that the browser discovers being offline and suppresses such calls. When WIFI is back ON, then the browser sends these requests. That was exactly what I saw in the Network tab. I searched and found an option to force browser to always send the request, regardless of what it thinks about connectivity. Such option, `networkMode: 'always'`, can be added to TanStackQuery client. I started working on adding this option to occurences of `useQuery` and `useMutation`, and immediately sounded success, as the behavior was correct. However, @xcrzx rigthfully pointed out, that it would be much better to only add it to one place, that is the configuration of the QueryClient. I did it, and to my surprise, the problem returned. I noticed that adding this option to the QueryClient in Fleet solved the problem in the Fleet tab immediately, but adding this option to the `SecuritySolutionQueryClient` does nothing, like it was completely ignored. I searched different options and spent two more days debugging the problem, but then, when paired up again with Dmitrii, he found that the `SecuritySolutionQueryClient` is overshadowed by some other QueryClient present in the stack of components much below, the `CasesContext`. That discovery enabled me to add this new setting to the other QueryClient, and this fixes the issue. However, we think that it will be worth investigating why we need this second context, as the situation when one QueryClient overshadows another one, smells badly and may be a source of other issues as well (I will reach out to the team responsible for the CasesContext and ask if we can unify this somehow). ## BEFORE https://github.com/user-attachments/assets/662dab73-b1bd-4d6b-9d15-c35efab679c6 ## AFTER https://github.com/user-attachments/assets/b905bde0-150d-478d-9734-9003fb5bcf66 ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 7ad35a4)

@111andre111

…e, for air-gapped environment. (elastic#220510) **Resolves: elastic#181808** ## Summary I am fixing the issue of the Rules and Alerts tabs in Security, as well as the Fleet tab in Management, that gets stalled in air-gapped environment. I am doing so by enforcing the request to be sent to the API even when offline. ### Historical context: During investigation of the original issue elastic#181808 I proved that Kibana doesn't try to reach to EPR in the air-gapped environment (that is, with the `xpack.fleet.isAirGapped: true` flag, and WIFI being turned ON). I commented this [here](elastic#181808 (comment)) and we closed the issue. However, @111andre111 reached out to us saying that this wasn't enough, as the real issue remains, that is, Kibana doesn't behave properly when: - `xpack.fleet.isAirGapped` flag is set to `true` - there is no Internet connection (WIFI off or cable physically disconnected) That's why we reopened the ticket and I restarted the investigation. My first observation was that when I turn off the WIFI, I cannot see requests to the API being sent in the Network tab in Dev Tools, most importantly to the `_bootstrap` endpoint at the first entrance to the Solution app, and other endpoints later. I searched that the browser discovers being offline and suppresses such calls. When WIFI is back ON, then the browser sends these requests. That was exactly what I saw in the Network tab. I searched and found an option to force browser to always send the request, regardless of what it thinks about connectivity. Such option, `networkMode: 'always'`, can be added to TanStackQuery client. I started working on adding this option to occurences of `useQuery` and `useMutation`, and immediately sounded success, as the behavior was correct. However, @xcrzx rigthfully pointed out, that it would be much better to only add it to one place, that is the configuration of the QueryClient. I did it, and to my surprise, the problem returned. I noticed that adding this option to the QueryClient in Fleet solved the problem in the Fleet tab immediately, but adding this option to the `SecuritySolutionQueryClient` does nothing, like it was completely ignored. I searched different options and spent two more days debugging the problem, but then, when paired up again with Dmitrii, he found that the `SecuritySolutionQueryClient` is overshadowed by some other QueryClient present in the stack of components much below, the `CasesContext`. That discovery enabled me to add this new setting to the other QueryClient, and this fixes the issue. However, we think that it will be worth investigating why we need this second context, as the situation when one QueryClient overshadows another one, smells badly and may be a source of other issues as well (I will reach out to the team responsible for the CasesContext and ask if we can unify this somehow). ## BEFORE https://github.com/user-attachments/assets/662dab73-b1bd-4d6b-9d15-c35efab679c6 ## AFTER https://github.com/user-attachments/assets/b905bde0-150d-478d-9734-9003fb5bcf66 ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The `release_note:breaking` label should be applied in these situations. - [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed - [ ] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit 7ad35a4)

@111andre111

… offline, for air-gapped environment. (#220510) (#225102) # Backport This will backport the following commits from `main` to `8.18`: - [[Security Solution] Enforce sending the request to API even if offline, for air-gapped environment. (#220510)](#220510)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport)  Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>

jkelas self-assigned this May 8, 2025

jkelas changed the title ~~Enforce sending the request to API even if offline, for air-gapped environment.~~ [Security Solution] Enforce sending the request to API even if offline, for air-gapped environment. May 8, 2025

jkelas marked this pull request as ready for review May 8, 2025 14:25

jkelas requested review from a team as code owners May 8, 2025 14:25

jkelas force-pushed the 181808_air_gapped_2 branch from 34657e5 to 7747529 Compare May 8, 2025 18:04

botelastic bot added the Team:Fleet Team label for Observability Data Collection Fleet team label May 8, 2025

nchaulet reviewed May 9, 2025

View reviewed changes

jkelas mentioned this pull request May 20, 2025

[Security Solution] Should not require EPR access in air-gapped environments #181808

Closed

jkelas force-pushed the 181808_air_gapped_2 branch from 7747529 to fae7e3b Compare May 20, 2025 14:34

Jacek Kolezynski added 2 commits May 21, 2025 10:13

Enforce the request even if offline, for air-gapped environment.

6628459

Suggestion from review

1371bdd

jkelas force-pushed the 181808_air_gapped_2 branch from 909ac82 to 1371bdd Compare May 21, 2025 08:13

jkelas marked this pull request as draft May 21, 2025 09:21

jkelas requested a review from a team May 21, 2025 09:28

dplumlee approved these changes Jun 5, 2025

View reviewed changes

Merge branch 'main' into 181808_air_gapped_2

d727eb4

jkelas removed the request for review from nchaulet June 6, 2025 14:27

cnasikas approved these changes Jun 10, 2025

View reviewed changes

Merge branch 'main' into 181808_air_gapped_2

c30d480

jkelas merged commit 7ad35a4 into elastic:main Jun 10, 2025
10 checks passed

kibanamachine mentioned this pull request Jun 10, 2025

[8.19] [Security Solution] Enforce sending the request to API even if offline, for air-gapped environment. (#220510) #223204

Merged

kibanamachine mentioned this pull request Jun 10, 2025

[9.0] [Security Solution] Enforce sending the request to API even if offline, for air-gapped environment. (#220510) #223205

Merged

kibanamachine added the v9.0.3 label Jun 10, 2025

jkelas added release_note:fix and removed release_note:skip Skip the PR/issue when compiling release notes labels Jun 18, 2025

jkelas deleted the 181808_air_gapped_2 branch June 18, 2025 16:18

banderror removed the v9.0.0 label Jun 24, 2025

jkelas mentioned this pull request Jun 24, 2025

[8.18] [Security Solution] Enforce sending the request to API even if offline, for air-gapped environment. (#220510) #225102

Merged

kibanamachine added the v8.18.4 label Jun 25, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Security Solution] Enforce sending the request to API even if offline, for air-gapped environment.#220510

[Security Solution] Enforce sending the request to API even if offline, for air-gapped environment.#220510
jkelas merged 12 commits intoelastic:mainfrom
jkelas:181808_air_gapped_2

jkelas commented May 8, 2025 •

edited by kibanamachine

Loading

Uh oh!

elasticmachine commented May 8, 2025

Uh oh!

elasticmachine commented May 8, 2025

Uh oh!

elasticmachine commented May 8, 2025

Uh oh!

elasticmachine commented May 8, 2025

Uh oh!

nchaulet May 9, 2025 •

edited

Loading

Uh oh!

jkelas May 20, 2025

Uh oh!

elasticmachine commented Jun 10, 2025

Uh oh!

Uh oh!

kibanamachine commented Jun 10, 2025

Uh oh!

kibanamachine commented Jun 10, 2025

Uh oh!

banderror commented Jun 24, 2025

Uh oh!

jkelas commented Jun 24, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

11 participants

Conversation

jkelas commented May 8, 2025 • edited by kibanamachine Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Historical context:

BEFORE

AFTER

Checklist

Uh oh!

elasticmachine commented May 8, 2025

Uh oh!

elasticmachine commented May 8, 2025

Uh oh!

elasticmachine commented May 8, 2025

Uh oh!

elasticmachine commented May 8, 2025

Uh oh!

nchaulet May 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkelas May 20, 2025

Choose a reason for hiding this comment

Uh oh!

elasticmachine commented Jun 10, 2025

💚 Build Succeeded

Metrics [docs]

Async chunks

Page load bundle

History

Uh oh!

Uh oh!

kibanamachine commented Jun 10, 2025

Uh oh!

kibanamachine commented Jun 10, 2025

💚 All backports created successfully

Questions ?

Uh oh!

banderror commented Jun 24, 2025

Uh oh!

jkelas commented Jun 24, 2025

💚 All backports created successfully

Questions ?

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

11 participants

jkelas commented May 8, 2025 •

edited by kibanamachine

Loading

nchaulet May 9, 2025 •

edited

Loading