Commit dfad25f
# 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)
<!--- Backport version: 9.6.6 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)
<!--BACKPORT [{"author":{"name":"Jacek
Kolezynski","email":"[email protected]"},"sourceCommit":{"committedDate":"2025-06-10T10:14:45Z","message":"[Security
Solution] Enforce sending the request to API even if offline, for
air-gapped environment. (#220510)\n\n**Resolves: #181808**\n\n##
Summary\n\nI am fixing the issue of the Rules and Alerts tabs in
Security, as well\nas the Fleet tab in Management, that gets stalled in
air-gapped\nenvironment. I am doing so by enforcing the request to be
sent to the\nAPI even when offline.\n\n### Historical context:\nDuring
investigation of the original issue #181808 I proved that
Kibana\ndoesn't try to reach to EPR in the air-gapped environment (that
is, with\nthe `xpack.fleet.isAirGapped: true` flag, and WIFI being
turned ON). I\ncommented
this\n[here](https://github.com/elastic/kibana/issues/181808#issuecomment-2829911511)\nand
we closed the issue. However, @111andre111 reached out to us
saying\nthat this wasn't enough, as the real issue remains, that is,
Kibana\ndoesn't behave properly when:\n- `xpack.fleet.isAirGapped` flag
is set to `true`\n- there is no Internet connection (WIFI off or cable
physically\ndisconnected)\n\nThat's why we reopened the ticket and I
restarted the investigation. \nMy first observation was that when I turn
off the WIFI, I cannot see\nrequests to the API being sent in the
Network tab in Dev Tools, most\nimportantly to the `_bootstrap` endpoint
at the first entrance to the\nSolution app, and other endpoints later. I
searched that the browser\ndiscovers being offline and suppresses such
calls. When WIFI is back ON,\nthen the browser sends these requests.
That was exactly what I saw in\nthe Network tab.\nI searched and found
an option to force browser to always send the\nrequest, regardless of
what it thinks about connectivity. Such option,\n`networkMode:
'always'`, can be added to TanStackQuery client.\n\nI started working on
adding this option to occurences of `useQuery` and\n`useMutation`, and
immediately sounded success, as the behavior was\ncorrect. However,
@xcrzx rigthfully pointed out, that it would be much\nbetter to only add
it to one place, that is the configuration of the\nQueryClient. I did
it, and to my surprise, the problem returned.\nI noticed that adding
this option to the QueryClient in Fleet solved the\nproblem in the Fleet
tab immediately, but adding this option to
the\n`SecuritySolutionQueryClient` does nothing, like it was
completely\nignored.\nI searched different options and spent two more
days debugging the\nproblem, but then, when paired up again with
Dmitrii, he found that the\n`SecuritySolutionQueryClient` is
overshadowed by some other QueryClient\npresent in the stack of
components much below, the `CasesContext`. That\ndiscovery enabled me to
add this new setting to the other QueryClient,\nand this fixes the
issue. However, we think that it will be worth\ninvestigating why we
need this second context, as the situation when one\nQueryClient
overshadows another one, smells badly and may be a source of\nother
issues as well (I will reach out to the team responsible for
the\nCasesContext and ask if we can unify this somehow).\n\n##
BEFORE\n\n\nhttps://github.com/user-attachments/assets/662dab73-b1bd-4d6b-9d15-c35efab679c6\n\n##
AFTER\n\n\nhttps://github.com/user-attachments/assets/b905bde0-150d-478d-9734-9003fb5bcf66\n\n\n\n###
Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers
should verify this PR satisfies this list as well.\n\n- [ ] [Unit or
functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere
updated or added to match the most common scenarios\n- [ ] If a plugin
configuration key changed, check if it needs to be\nallowlisted in the
cloud and added to the
[docker\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\n-
[ ] This was checked for breaking HTTP API changes, and any
breaking\nchanges have been approved by the breaking-change committee.
The\n`release_note:breaking` label should be applied in these
situations.\n- [ ] [Flaky
Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1)
was\nused on any tests changed\n- [ ] The PR description includes the
appropriate Release Notes section,\nand the correct `release_note:*`
label is applied per
the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\n\n---------\n\nCo-authored-by:
kibanamachine
<[email protected]>","sha":"7ad35a4a33c3bd4d4f4e33acff20f4ebaa3242ce","branchLabelMapping":{"^v9.1.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:skip","Team:Fleet","v9.0.0","Team:Detections
and Resp","Team: SecuritySolution","Team:Detection Rule
Management","ci:build-all-platforms","ci:build-os-packages","Feature:Prebuilt
Detection
Rules","ci:build-cloud-image","backport:version","v9.1.0","v8.19.0"],"title":"[Security
Solution] Enforce sending the request to API even if offline, for
air-gapped
environment.","number":220510,"url":"https://github.com/elastic/kibana/pull/220510","mergeCommit":{"message":"[Security
Solution] Enforce sending the request to API even if offline, for
air-gapped environment. (#220510)\n\n**Resolves: #181808**\n\n##
Summary\n\nI am fixing the issue of the Rules and Alerts tabs in
Security, as well\nas the Fleet tab in Management, that gets stalled in
air-gapped\nenvironment. I am doing so by enforcing the request to be
sent to the\nAPI even when offline.\n\n### Historical context:\nDuring
investigation of the original issue #181808 I proved that
Kibana\ndoesn't try to reach to EPR in the air-gapped environment (that
is, with\nthe `xpack.fleet.isAirGapped: true` flag, and WIFI being
turned ON). I\ncommented
this\n[here](https://github.com/elastic/kibana/issues/181808#issuecomment-2829911511)\nand
we closed the issue. However, @111andre111 reached out to us
saying\nthat this wasn't enough, as the real issue remains, that is,
Kibana\ndoesn't behave properly when:\n- `xpack.fleet.isAirGapped` flag
is set to `true`\n- there is no Internet connection (WIFI off or cable
physically\ndisconnected)\n\nThat's why we reopened the ticket and I
restarted the investigation. \nMy first observation was that when I turn
off the WIFI, I cannot see\nrequests to the API being sent in the
Network tab in Dev Tools, most\nimportantly to the `_bootstrap` endpoint
at the first entrance to the\nSolution app, and other endpoints later. I
searched that the browser\ndiscovers being offline and suppresses such
calls. When WIFI is back ON,\nthen the browser sends these requests.
That was exactly what I saw in\nthe Network tab.\nI searched and found
an option to force browser to always send the\nrequest, regardless of
what it thinks about connectivity. Such option,\n`networkMode:
'always'`, can be added to TanStackQuery client.\n\nI started working on
adding this option to occurences of `useQuery` and\n`useMutation`, and
immediately sounded success, as the behavior was\ncorrect. However,
@xcrzx rigthfully pointed out, that it would be much\nbetter to only add
it to one place, that is the configuration of the\nQueryClient. I did
it, and to my surprise, the problem returned.\nI noticed that adding
this option to the QueryClient in Fleet solved the\nproblem in the Fleet
tab immediately, but adding this option to
the\n`SecuritySolutionQueryClient` does nothing, like it was
completely\nignored.\nI searched different options and spent two more
days debugging the\nproblem, but then, when paired up again with
Dmitrii, he found that the\n`SecuritySolutionQueryClient` is
overshadowed by some other QueryClient\npresent in the stack of
components much below, the `CasesContext`. That\ndiscovery enabled me to
add this new setting to the other QueryClient,\nand this fixes the
issue. However, we think that it will be worth\ninvestigating why we
need this second context, as the situation when one\nQueryClient
overshadows another one, smells badly and may be a source of\nother
issues as well (I will reach out to the team responsible for
the\nCasesContext and ask if we can unify this somehow).\n\n##
BEFORE\n\n\nhttps://github.com/user-attachments/assets/662dab73-b1bd-4d6b-9d15-c35efab679c6\n\n##
AFTER\n\n\nhttps://github.com/user-attachments/assets/b905bde0-150d-478d-9734-9003fb5bcf66\n\n\n\n###
Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers
should verify this PR satisfies this list as well.\n\n- [ ] [Unit or
functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere
updated or added to match the most common scenarios\n- [ ] If a plugin
configuration key changed, check if it needs to be\nallowlisted in the
cloud and added to the
[docker\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\n-
[ ] This was checked for breaking HTTP API changes, and any
breaking\nchanges have been approved by the breaking-change committee.
The\n`release_note:breaking` label should be applied in these
situations.\n- [ ] [Flaky
Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1)
was\nused on any tests changed\n- [ ] The PR description includes the
appropriate Release Notes section,\nand the correct `release_note:*`
label is applied per
the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\n\n---------\n\nCo-authored-by:
kibanamachine
<[email protected]>","sha":"7ad35a4a33c3bd4d4f4e33acff20f4ebaa3242ce"}},"sourceBranch":"main","suggestedTargetBranches":["9.0","8.19"],"targetPullRequestStates":[{"branch":"9.0","label":"v9.0.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/220510","number":220510,"mergeCommit":{"message":"[Security
Solution] Enforce sending the request to API even if offline, for
air-gapped environment. (#220510)\n\n**Resolves: #181808**\n\n##
Summary\n\nI am fixing the issue of the Rules and Alerts tabs in
Security, as well\nas the Fleet tab in Management, that gets stalled in
air-gapped\nenvironment. I am doing so by enforcing the request to be
sent to the\nAPI even when offline.\n\n### Historical context:\nDuring
investigation of the original issue #181808 I proved that
Kibana\ndoesn't try to reach to EPR in the air-gapped environment (that
is, with\nthe `xpack.fleet.isAirGapped: true` flag, and WIFI being
turned ON). I\ncommented
this\n[here](https://github.com/elastic/kibana/issues/181808#issuecomment-2829911511)\nand
we closed the issue. However, @111andre111 reached out to us
saying\nthat this wasn't enough, as the real issue remains, that is,
Kibana\ndoesn't behave properly when:\n- `xpack.fleet.isAirGapped` flag
is set to `true`\n- there is no Internet connection (WIFI off or cable
physically\ndisconnected)\n\nThat's why we reopened the ticket and I
restarted the investigation. \nMy first observation was that when I turn
off the WIFI, I cannot see\nrequests to the API being sent in the
Network tab in Dev Tools, most\nimportantly to the `_bootstrap` endpoint
at the first entrance to the\nSolution app, and other endpoints later. I
searched that the browser\ndiscovers being offline and suppresses such
calls. When WIFI is back ON,\nthen the browser sends these requests.
That was exactly what I saw in\nthe Network tab.\nI searched and found
an option to force browser to always send the\nrequest, regardless of
what it thinks about connectivity. Such option,\n`networkMode:
'always'`, can be added to TanStackQuery client.\n\nI started working on
adding this option to occurences of `useQuery` and\n`useMutation`, and
immediately sounded success, as the behavior was\ncorrect. However,
@xcrzx rigthfully pointed out, that it would be much\nbetter to only add
it to one place, that is the configuration of the\nQueryClient. I did
it, and to my surprise, the problem returned.\nI noticed that adding
this option to the QueryClient in Fleet solved the\nproblem in the Fleet
tab immediately, but adding this option to
the\n`SecuritySolutionQueryClient` does nothing, like it was
completely\nignored.\nI searched different options and spent two more
days debugging the\nproblem, but then, when paired up again with
Dmitrii, he found that the\n`SecuritySolutionQueryClient` is
overshadowed by some other QueryClient\npresent in the stack of
components much below, the `CasesContext`. That\ndiscovery enabled me to
add this new setting to the other QueryClient,\nand this fixes the
issue. However, we think that it will be worth\ninvestigating why we
need this second context, as the situation when one\nQueryClient
overshadows another one, smells badly and may be a source of\nother
issues as well (I will reach out to the team responsible for
the\nCasesContext and ask if we can unify this somehow).\n\n##
BEFORE\n\n\nhttps://github.com/user-attachments/assets/662dab73-b1bd-4d6b-9d15-c35efab679c6\n\n##
AFTER\n\n\nhttps://github.com/user-attachments/assets/b905bde0-150d-478d-9734-9003fb5bcf66\n\n\n\n###
Checklist\n\nCheck the PR satisfies following conditions. \n\nReviewers
should verify this PR satisfies this list as well.\n\n- [ ] [Unit or
functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere
updated or added to match the most common scenarios\n- [ ] If a plugin
configuration key changed, check if it needs to be\nallowlisted in the
cloud and added to the
[docker\nlist](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)\n-
[ ] This was checked for breaking HTTP API changes, and any
breaking\nchanges have been approved by the breaking-change committee.
The\n`release_note:breaking` label should be applied in these
situations.\n- [ ] [Flaky
Test\nRunner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1)
was\nused on any tests changed\n- [ ] The PR description includes the
appropriate Release Notes section,\nand the correct `release_note:*`
label is applied per
the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)\n\n---------\n\nCo-authored-by:
kibanamachine
<[email protected]>","sha":"7ad35a4a33c3bd4d4f4e33acff20f4ebaa3242ce"}},{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
Co-authored-by: Jacek Kolezynski <[email protected]>
1 parent 2b3122e commit dfad25f
File tree
4 files changed
+35
-4
lines changed- x-pack
- solutions/security/plugins/security_solution/public/common/containers/query_client
4 files changed
+35
-4
lines changedLines changed: 10 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
7 | 7 | | |
8 | 8 | | |
9 | 9 | | |
10 | | - | |
| 10 | + | |
| 11 | + | |
| 12 | + | |
| 13 | + | |
| 14 | + | |
| 15 | + | |
| 16 | + | |
| 17 | + | |
| 18 | + | |
| 19 | + | |
Lines changed: 10 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
65 | 65 | | |
66 | 66 | | |
67 | 67 | | |
68 | | - | |
| 68 | + | |
| 69 | + | |
| 70 | + | |
| 71 | + | |
| 72 | + | |
| 73 | + | |
| 74 | + | |
| 75 | + | |
| 76 | + | |
| 77 | + | |
69 | 78 | | |
70 | 79 | | |
71 | 80 | | |
| |||
Lines changed: 10 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
44 | 44 | | |
45 | 45 | | |
46 | 46 | | |
47 | | - | |
| 47 | + | |
| 48 | + | |
| 49 | + | |
| 50 | + | |
| 51 | + | |
| 52 | + | |
| 53 | + | |
| 54 | + | |
| 55 | + | |
| 56 | + | |
48 | 57 | | |
49 | 58 | | |
50 | 59 | | |
| |||
Lines changed: 5 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
25 | 25 | | |
26 | 26 | | |
27 | 27 | | |
28 | | - | |
| 28 | + | |
| 29 | + | |
| 30 | + | |
| 31 | + | |
| 32 | + | |
29 | 33 | | |
30 | 34 | | |
31 | 35 | | |
| |||
0 commit comments