Currently, we are only logging the last error when we fail to connect to
any of the addresses from the portal. This is often not useful because
the last one is likely to be an IPv6 address which may not be supported
on the system so all we learn is "The requested address is not valid in
its context.".
The error code we see here means "There are no more endpoints available
from the endpoint mapper." This has something to do with Windows'
internal RPC communication between components. DNS deactivation is on a
best-effort basis and it appears that everything else is working just
fine, despite this error.
It appears to happen when we shut down our own service, so perhaps it is
just a race condition.
Whether we execute a task on the main thread or a background thread
doesn't affect whether the thread is "hung" as reported by Sentry.
Instead, our options for fixing these are:
- Try to use an async version of the underlying API (the [async
version](https://developer.apple.com/documentation/appkit/nsworkspace/open(_:configuration:completionhandler:))
of `open` for example)
- If there is none, and the call could potentially block (most likely to
do disk IO contention), at least schedule this on a new thread using
`Task.detached` but with `.background` priority so that it will avoid
blocking any other execution.
The main takeaway here is that unfortunately, under some conditions,
Sentry will _always_ report an "App Hanging" alert since it's constantly
monitoring all threads for paused execution longer than 2000ms.
We'll probably end up letting some of these slide (pausing a background
or worker thread isn't necessarily a UX issue), but pausing the UI
thread is.
Luckily, we're able to use async APIs for most things. The remaining
things (like working with log files over IPC) we use a `Task.detached`
for.
We currently have a bug in our changelog where the wrong download links
are being rendered for the Windows GUI client because we are incorrectly
matching on the title.
To fix this, we stop matching on the title and instead pass an `OS` enum
in the respective changelog components that need to differentiate
between OS-specific entries.
We've previously tried to handle the "No such process" error from
netlink when it tries to remove a route that no longer exists. What we
failed to do is use the correct sign for the error code as netlink
errors are always negative, yet when printed, the are positive numbers.
When an IP stack is programmatically disabled, such as with:
> reg add
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters"
/v DisabledComponents /t REG_DWORD /d 255 /f
Attempting to interact with this IP stack will yield "NOT_FOUND" errors.
These aren't worth reporting to Sentry because there isn't much we can
do about it.
Whenever changing a URL we care about, we add an entry in
`website/redirects.js` to avoid breaking links to the old page. Most
search engines reindex these after 1 year, but other websites and places
won't, so we should generally keep them indefinitely since they don't
cost us much to keep around.
We have a bug in our Rust telemetry code where starting a new telemetry
session for an **unsupported** environment doesn't stop the previous one
if one already exists.
This results in very confusing Sentry issues that cannot be correlated
to our infrastructure.
The errors returned from Win32 API calls are currently duplicated in
several places. To makes it error-prone to handle them correctly. With
this PR, we de-duplicate this and add proper docs and links for further
reading to them.
We also fix a case where we would currently fail to set IP addresses for
our tunnel interface if the IP stack is not supported.
`fetchResources` is an IPC call, and we can use
`withCheckedThrowingContinuation` like the others to yield while we wait
for the provider to respond.
The particular sentry issue related to this isn't because we are
necessarily blocking the task thread, rather, I suspect it's when
applying the fetched Resources to the UI that we're slow. There isn't
much we can do about this, but this PR will only help.
Because we're using a timer that fires off a closure to do this, we
still use a `callback` inside the timer to actually set the Resources on
the main `Store`, which updates the UI.
Unfortunately refactoring these IPC calls lead to somewhat of a ball of
yarn, so the best way to summarize the spirit of this PR is:
- Ensure IPC calls use `withCheckedThrowingContinuation` where possible
- Thusly, marking these functions `async throws`
- Bubble these errors up the view where we can ultimately decide what to
do with them
- Keep VPN state management and conditional logic based on `NEVPNStatus`
in the vpnConfigurationManager
In order to test changes to the IPC service on Windows more easily, the
IPC service binary offers an `install` command that installs a new
"Debug" IPC service. Prior to that, the previous is uninstalled.
This doesn't work if one doesn't have a previous "Debug" IPC service so
the `install` command only works for devs that have at least run it once
with that part of the function commented out. To improve this Dev UX, we
don't abort if we can't uninstall the previous one.
This adds hardening to the relay example systemd service shown in the
admin portal. Instead of running the service as root to download the
relay binary, we can let systemd manage the state directory and run with
lower privileges at all times.
I've also removed a shell injection which would in theory allow a
malicious github api server to run commands as root in the pre start
phase.
That being said I have no idea how this script is intended to function,
since it downloads the relay binary from the latest release on GitHub
which currently is a `gui-client` release without any relay binaries
attached.
We are getting quite a few of these warnings on prod:
```
{400, "{\n \"error\": {\n \"code\": 400,\n \"message\": \"One or more TimeSeries could not be written: timeSeries[0-39]: write for resource=gce_instance{zone:us-east1-d,instance_id:2678918148122610092} failed with: One or more points were written more frequently than the maximum sampling period configured for the metric.\",\n \"status\": \"INVALID_ARGUMENT\",\n \"details\": [\n {\n \"@type\": \"type.googleapis.com/google.monitoring.v3.CreateTimeSeriesSummary\",\n \"totalPointCount\": 40,\n \"successPointCount\": 31,\n \"errors\": [\n {\n \"status\": {\n \"code\": 9\n },\n \"pointCount\": 9\n }\n ]\n }\n ]\n }\n}\n"}
```
Since the point count is _much_ less than our flush buffer size of 1000,
we can only surmise the limit we're hitting is the flush interval.
The telemetry metrics reporter is run on each node, so we run the risk
of violating Google's API limit regardless of what a single node's
`@flush_interval` is set to.
To solve this, we use a new table `telemetry_reporter_logs` that stores
the last time a particular `flush` occurred for a reporter module. This
tracks global state as to when the last flush occurred, and if too
recent, the timer-based flush is call is `no-op`ed until the next one.
**Note**: The buffer-based `flush` is left unchanged, this will always
be called when `buffer_size > max_buffer_size`.
We are quite a few versions behind.
The changelog lists a good amount of [Breaking API
changes](https://github.com/open-telemetry/opentelemetry-collector/releases),
but rather than enumerate all of those, or forever stay on the same
(ancient) version, I thought it would be a good idea to flex the upgrade
muscle here and see where it lands us on staging.
Bumps [sd-notify](https://github.com/lnicola/sd-notify) from 0.4.3 to
0.4.5.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/lnicola/sd-notify/blob/master/CHANGELOG.md">sd-notify's
changelog</a>.</em></p>
<blockquote>
<h2>[0.4.5] - 2025-01-18</h2>
<h3>Fixed</h3>
<ul>
<li>fixed a dubious transmute between different slice types</li>
</ul>
<h2>[0.4.4] - 2025-01-16</h2>
<h3>Added</h3>
<ul>
<li>added <code>NotifyState::MonotonicUsec</code>, for use with
<code>Type=notify-reload</code></li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="70a941baf1"><code>70a941b</code></a>
Bump to 0.4.5</li>
<li><a
href="6958ce12e4"><code>6958ce1</code></a>
Merge pull request <a
href="https://redirect.github.com/lnicola/sd-notify/issues/15">#15</a>
from tbu-/pr_slice_transmute</li>
<li><a
href="1e938f2fd5"><code>1e938f2</code></a>
Use <code>slice::from_raw_parts</code> instead of
<code>mem::transmute</code></li>
<li><a
href="cb4459a4bb"><code>cb4459a</code></a>
Prepare for new release</li>
<li><a
href="8eb2c5cab3"><code>8eb2c5c</code></a>
Add NotifyState::MonotonicUsec and helper</li>
<li><a
href="5462699164"><code>5462699</code></a>
Add NotifyState::MonotonicUsec and helper</li>
<li><a
href="6990e3733f"><code>6990e37</code></a>
Fix clippy warnings</li>
<li>See full diff in <a
href="https://github.com/lnicola/sd-notify/compare/v0.4.3...v0.4.5">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [clap](https://github.com/clap-rs/clap) from 4.5.21 to 4.5.28.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/clap-rs/clap/releases">clap's
releases</a>.</em></p>
<blockquote>
<h2>v4.5.28</h2>
<h2>[4.5.28] - 2025-02-03</h2>
<h3>Features</h3>
<ul>
<li><em>(derive)</em> Unstable support for full markdown syntax for doc
comments, enabled with <code>unstable-markdown</code></li>
</ul>
<h2>v4.5.27</h2>
<h2>[4.5.27] - 2025-01-20</h2>
<h3>Documentation</h3>
<ul>
<li>Iterate on tutorials and reference based on feedback</li>
</ul>
<h2>v4.5.26</h2>
<h2>[4.5.26] - 2025-01-09</h2>
<h3>Fixes</h3>
<ul>
<li><em>(error)</em> Reduce binary size with the
<code>suggestions</code> feature</li>
</ul>
<h2>v4.5.25</h2>
<h2>[4.5.25] - 2025-01-09</h2>
<h3>Fixes</h3>
<ul>
<li><em>(help)</em> Reduce binary size</li>
</ul>
<h2>v4.5.24</h2>
<h2>[4.5.24] - 2025-01-07</h2>
<h3>Fixes</h3>
<ul>
<li><em>(parser)</em> Correctly handle defaults with
<code>ignore_errors(true)</code> and when a suggestion is provided for
an unknown argument</li>
</ul>
<h2>v4.5.23</h2>
<h2>[4.5.23] - 2024-12-05</h2>
<h3>Fixes</h3>
<ul>
<li><em>(parser)</em> When check <code>allow_negative_numbers</code>,
allow <code>E</code> again</li>
</ul>
<h2>v4.5.22</h2>
<h2>[4.5.22] - 2024-12-03</h2>
<h3>Fixes</h3>
<ul>
<li><em>(assert)</em> Catch bugs with arguments requiring themself</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/clap-rs/clap/blob/master/CHANGELOG.md">clap's
changelog</a>.</em></p>
<blockquote>
<h2>[4.5.28] - 2025-02-03</h2>
<h3>Features</h3>
<ul>
<li><em>(derive)</em> Unstable support for full markdown syntax for doc
comments, enabled with <code>unstable-markdown</code></li>
</ul>
<h2>[4.5.27] - 2025-01-20</h2>
<h3>Documentation</h3>
<ul>
<li>Iterate on tutorials and reference based on feedback</li>
</ul>
<h2>[4.5.26] - 2025-01-09</h2>
<h3>Fixes</h3>
<ul>
<li><em>(error)</em> Reduce binary size with the
<code>suggestions</code> feature</li>
</ul>
<h2>[4.5.25] - 2025-01-09</h2>
<h3>Fixes</h3>
<ul>
<li><em>(help)</em> Reduce binary size</li>
</ul>
<h2>[4.5.24] - 2025-01-07</h2>
<h3>Fixes</h3>
<ul>
<li><em>(parser)</em> Correctly handle defaults with
<code>ignore_errors(true)</code> and when a suggestion is provided for
an unknown argument</li>
</ul>
<h2>[4.5.23] - 2024-12-05</h2>
<h3>Fixes</h3>
<ul>
<li><em>(parser)</em> When check <code>allow_negative_numbers</code>,
allow <code>E</code> again</li>
</ul>
<h2>[4.5.22] - 2024-12-03</h2>
<h3>Fixes</h3>
<ul>
<li><em>(assert)</em> Catch bugs with arguments requiring themself</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="257d7812b9"><code>257d781</code></a>
chore: Release</li>
<li><a
href="06c5f5f329"><code>06c5f5f</code></a>
docs: Update changelog</li>
<li><a
href="6ac153557c"><code>6ac1535</code></a>
Merge pull request <a
href="https://redirect.github.com/clap-rs/clap/issues/5733">#5733</a>
from epage/bin</li>
<li><a
href="a7a8f93d6b"><code>a7a8f93</code></a>
fix(complete): Strip wrappers for running completer</li>
<li><a
href="b2c8e445aa"><code>b2c8e44</code></a>
feat(complete): Allow user to override bin/completer</li>
<li><a
href="21c9892efe"><code>21c9892</code></a>
chore: Release</li>
<li><a
href="0c8bceb3e9"><code>0c8bceb</code></a>
docs: Update changelog</li>
<li><a
href="d8f102a18c"><code>d8f102a</code></a>
Merge pull request <a
href="https://redirect.github.com/clap-rs/clap/issues/5732">#5732</a>
from epage/consistent</li>
<li><a
href="c92fca3a8f"><code>c92fca3</code></a>
docs(complete): Clarify CompleteEnv's Shell trait</li>
<li><a
href="5ca60e9079"><code>5ca60e9</code></a>
Merge pull request <a
href="https://redirect.github.com/clap-rs/clap/issues/5731">#5731</a>
from epage/bash</li>
<li>Additional commits viewable in <a
href="https://github.com/clap-rs/clap/compare/clap_complete-v4.5.21...clap_complete-v4.5.28">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Followup to the discussion on
https://github.com/firezone/firezone/pull/8064. By annotating the
callback that updates our Resources `@MainActor`, the compiler will
correctly warn us when we call it from a non-isolated context.
When the IPC service gets terminated gracefully, the user must have
initiated some kind of action, be it an upgrade or an explicit "Stop the
service". In that case, there is no point in displaying an alert with an
info / error message as the user already knows that they are stopping
Firezone. In order to not fatigue the user with alerts, we exit the GUI
with a toast notification when the IPC service shuts down gracefully.
Toast notifications do not grab the users attention, allowing them to
continue what they are doing while still being notified that their
Firezone client is now disconnected.
Fixes: #6232.
If we receive two `.connected` status change updates from the system in
a row, we'll incorrectly schedule an additional timer, and the handle to
the first one will be lost.
This causes a memory leak because we'll then never call the first
timer's `invalidate()` function in the `endUpdatingResources` call.
This fixes a bug introduced in db655dd171 that could lead to a crash or
undefined behavior because it potentially updates resources (a
`@Published` object) from a background thread.
UI updates must occur on the main thread only.
The `load` and `save` functions in `Favorites` perform disk I/O and
should be wrapped with `withCheckedContinuation` in order to allow these
to be managed by the async runtime.
This was causing a detected hang on some devices with limited disk I/O
resources.
So it turns out we can get around the whole modal-blocking issue by
wrapping the `runModal()` call in `withCheckedContinuation`.
The key takeaway here is that `withCheckedContinuation` can be used to
wrap calls that can block I/O, marking them async, and allowing the Task
executor to do other useful work. This can even take place on on the
main thread.
Bear in mind `withCheckedContinuation` (and friends) *will not* prevent
blocking the task executor if the code being called is CPU-bottlenecked
in nature, such as calculating prime numbers or something. In those
cases, even `Task.detached` will cause Sentry to report `App Hanging`
alerts.
In short, only `Task.detached` when the I/O-related work to perform does
not depend on the current context and can be executed completely
independently of the parent, such as downloading image files in the
background or something.
This adds the following for the headless Windows client:
- website download redirects to use for permalinks
- Windows headless client user guide
It also cleans up old references and a few minor related things I found
while working on this.
This publishes the windows headless client using the same convention set
forth by the linux headless client.
Docs and website changes will come in a subsequent PR.
Related: #3782Resolves: #8046
As discussed with @bmanifold, we're moving forward with the following
monitoring strategy:
For infra alerts, stick with GCP.
For application-level alerts, use Sentry.
Since we already have Sentry configured and working on staging, this PR
removes the "Errors in logs" alert since we will be receiving this in
Sentry going forward.
This is required to run multiple components on a single machine (even if
the processes are sandboxed), since they will share a network namespace
and thus cannot bind to the same port.
Currently port `4000` is hardcoded, this PR allows this to be configured
by an environment variable.
---------
Co-authored-by: oddlama <oddlama@oddlama.org>
Developing on Windows is much easier if all Rust code compiles without
errors or warnings because you can "trust" your IDE that your code is
error free if it says "0 errors; 0 warnings". We are not far off from
achieving this!
Apart from the "graceful termination" feature in the relay, both the
relay and gateway should actually also work on Windows just fine, thanks
to the platform-agnostic abstractions we have been building up for the
GUI and headless client.
When the IPC service is shutdown gracefully (i.e. purposely), we send a
`TerminatingGracefully` message of the IPC channel. This allows the GUI
to handle this case differently from the a crash.
On Linux, this is achieved by reacting to signals that are sent to the
IPC process. Windows however doesn't send any signals to services.
Instead, we get an event that we are being shutdown.
Currently, this event is handled separately from the signal handler and
the signal handler does nothing on Windows. To make this more uniform
and allow graceful shutdown of the IPC service on Windows, we introduce
a 2nd constructor to the `Terminate` signal abstraction that is already
hooked up with the correct logic here.
As it turns out, the effort in #7104 was not a good idea. By logging
errors as values, most of our Sentry reports all have the same title and
thus cannot be differentiated from within the overview at all. To fix
this, we stringify errors with all their sources whenever they got
logged. This ensures log messages are unique and all Sentry issues will
have a useful title.
This is mostly to stay up to date with current Elixir and benefit from
the new included [JSON parser](https://hexdocs.pm/elixir/JSON.html).
Removing `Jason` in favor of the embedded `JSON` parser is saved for a
[future PR](https://github.com/firezone/firezone/issues/8011).
It found a couple type violations which were simple to fix, and some
formatting changes.
It appears that something is initializing the Sentry.LoggerHandler
before we try to load it when starting:
```
Invalid logger handler config: {:logger,
{:invalid_handler, {:function_not_exported, {Sentry.LoggerHandler, :log, 2}}}}
```
This doesn't seem to actually inhibit the Sentry logger at all,
presumably because it initializes just fine in the application start
callback.
Instead of defining the config in the `config/` directory, we can pass
it directly to `:logger` on start which solves the above issue.
On staging (only), we see these logs spammed:
```
{400, "{\n \"error\": {\n \"code\": 400,\n \"message\": \"One or more TimeSeries could not be written: timeSeries[22]: Metric kind for metric custom.googleapis.com/elixir/domain/repo/query/queue_time/min must be CUMULATIVE, but is GAUGE.; timeSeries[11]: Metric kind for metric custom.googleapis.com/elixir/domain/repo/query/query_time/max must be CUMULATIVE, but is GAUGE.; timeSeries[8]: Metric kind for metric custom.googleapis.com/elixir/domain/repo/query/idle_time/max must be CUMULATIVE, but is GAUGE.; timeSeries[7]: Metric kind for metric custom.googleapis.com/elixir/domain/repo/query/idle_time/min must be CUMULATIVE, but is GAUGE.; timeSeries[10]: Metric kind for metric custom.googleapis.com/elixir/domain/repo/query/query_time/min must be CUMULATIVE, but is GAUGE.; timeSeries[14]: Metric kind for metric custom.googleapis.com/elixir/domain/repo/query/query_time/max must be CUMULATIVE, but is GAUGE.; timeSeries[13]: Metric kind for metric custom.googleapis.com/elixir/domain/repo/query/query_time/min must be CUMULATIVE, but is GAUGE.; timeSeries[16]: Metric kind for metric custom.googleapis.com/elixir/domain/repo/query/query_time/min must be CUMULATIVE, but is GAUGE.; timeSeries[23]: Metric kind for metric custom.googleapis.com/elixir/domain/repo/query/queue_time/max must be CUMULATIVE, but is GAUGE.; timeSeries[20]: Metric kind for metric custom.googleapis.com/elixir/domain/repo/query/query_time/max must be CUMULATIVE, but is GAUGE.; timeSeries[19]: Metric kind for metric custom.googleapis.com/elixir/domain/repo/query/query_time/min must be CUMULATIVE, but is GAUGE.; timeSeries[17]: Metric kind for metric custom.googleapis.com/elixir/domain/repo/query/query_time/max must be CUMULATIVE, but is GAUGE.\",\n \"status\": \"INVALID_ARGUMENT\",\n \"details\": [\n {\n \"@type\": \"type.googleapis.com/google.monitoring.v3.CreateTimeSeriesSummary\",\n \"totalPointCount\": 36,\n \"successPointCount\": 24,\n \"errors\": [\n {\n \"status\": {\n \"code\": 3\n },\n \"pointCount\": 12\n }\n ]\n }\n ]\n }\n}\n"}
```
This does not happen on prod. As far as I can tell, GCP will cache the
initial metric kind used when the metric ID was first used, which
appears to be `CUMULATIVE` here.
The correct metric kind for these is `GAUGE` since they're reporting a
min/max value.
Since GCP doesn't support resetting the auto-defined metric kind of a
particular metric ID, we need to alter the ID to "bust" the cache and
create a new definition.
The applications within our umbrella are all joined into a single Erlang
cluster, and logger configuration is applied already to the entire
umbrella.
As such, registering the Sentry log handler in each application's
startup routine triggers duplicate handlers to be registered for the
cluster, resulting in warnings like this in GCP:
```
Event dropped due to being a duplicate of a previously-captured event.
```
As such, we can move the log handler configuration to the top-level
`:logger` key, under the `:logger` subkey for configuring a single
handler. We then load this handler config in the `domain` app only and
it applies to the entire cluster.
`e2-micro` is what we use for Relays and should be more than capable to
use for our internal prod Gateways for accessing the prod env.
Cost savings is about 3-4x vs `n1-standard-1`.
At present, the GUI client uses a monolithic `Error` enum that
represents all kinds of errors. Some of them are unused (see #7956).
Others are only used during startup, like the `deep_link` and
`WebViewNotInstalled` variants. This makes it difficult to write correct
error handling code.
In addition to remove certain variants in #7965, this PR refactors the
`run::gui` function to not depend on this `Error` at all. Instead, we
use `anyhow::Result` and probe for particular errors that we want to
special-case. This is a bit less type-safe because there is no source
code-level connection between the source site that emits an error and
the error handling code.
In the worst case, any regression here is "just" a slight degradation in
UX: We will show a generic error dialog instead of a tailored message.
This risk is deemed acceptable in exchange for an easier to understand
control flow.
