mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 10:18:54 +00:00
e9a863dc0e1ed4699454699a0a622bdcb5dfd5df
7850 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
e9a863dc0e |
fix(apple): use all found system resolvers (#9991)
When validating the found system resolvers on macOS and iOS, we would stop after validating the first found resolver (usually IPv4) because `break` was used instead of `continue`. Fixes #9914 --------- Signed-off-by: Thomas Eizinger <thomas@eizinger.io> Co-authored-by: Thomas Eizinger <thomas@eizinger.io> |
||
|
|
aebfcd56eb |
fix(connlib): resend candidates on connection upsert (#9986)
Due to network partitions between the Client and the Portal, it is possible that a Client requests a new connection, then disconnects from the portal and re-requests the connection once it is reconnected. On the Gateway, we would have already authorized the first request and initialise our ICE agents with our local candidates. The second time around, the connection would be reused. The Client however has lost its state and therefore, we need to tell it our candidates again. --------- Signed-off-by: Thomas Eizinger <thomas@eizinger.io> |
||
|
|
cbe114bddc |
fix(connlib): clear join requests on reconnect (#9985)
Room join requests on the portal are only valid whilst we have a WebSocket connection. To make sure the portal processes all our requests correctly, we need to hold all other messages back while we are waiting to join the room. If the connection flaps while we are waiting to join a room, we may have a lingering join request that never gets fulfilled and thus blocks the sending of messages forever. --------- Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com> |
||
|
|
f9721a1da6 |
fix(snownet): only idle when we are fully connected (#9987)
Now that we are capable of migrating a connection to another relay with #9979, our test suite exposed an edge-case: If we are in the middle of migrating a connection, it could be that the idle timer triggers because we have not seen any application traffic in the last 20s. Moving to idle mode drastically reduces the number of STUN bindings we send and if this happens whilst we are still checking candidates, the nomination doesn't happen in time for our boringtun handshake to succeed. Thus, we add a condition to our idle timer to not trigger unless ICE has completed and reports us as `connected`. |
||
|
|
79f698dff3 | docs(changelog): improve wording of entry for #9979 (#9988) | ||
|
|
d7b9ecb60b |
feat(gateway): update expiry of access authoritzations on init (#9975)
Resolves: #9971 |
||
|
|
dacc402721 |
chore(connlib): only log span field name into message (#9981)
When looking at logs, reducing noise is critical to make it easier to spot important information. When sending logs to Sentry, we currently append the fields of certain spans to message to make the output similar to that of `tracing_subscriber::fmt`. The actual name of a field inside a span is separated from the span name by a colon. For example, here is a log message as we see it in Sentry today: > handle_input:class=success response handle_input:from=C1A0479AA153FACA0722A5DF76343CF2BEECB10E:3478 handle_input:method=binding handle_input:rtt=34.7479ms handle_input:tid=BB30E859ED88FFDF0786B634 request=["Software(snownet; session=BCA42EF159C794F41AE45BF5099E54D3A193A7184C4D2C3560C2FE49C4C6CFB7)"] response=["Software(firezone-relay; rev=e4ba5a69)", "XorMappedAddress(B824B4035A78A6B188EF38BE13AA3C1B1B1196D6:52625)"] Really, what we would like to see is only this: > class=success response from=C1A0479AA153FACA0722A5DF76343CF2BEECB10E:3478 method=binding rtt=34.7479ms tid=BB30E859ED88FFDF0786B634 request=["Software(snownet; session=BCA42EF159C794F41AE45BF5099E54D3A193A7184C4D2C3560C2FE49C4C6CFB7)"] response=["Software(firezone-relay; rev=e4ba5a69)", "XorMappedAddress(B824B4035A78A6B188EF38BE13AA3C1B1B1196D6:52625)"] The duplication of `handle_input:` is just noise. In our local log output, we already strip the name of the span to make it easier to read. Here we now also do the same for the logs reported to Sentry. |
||
|
|
301d2137e5 |
refactor(windows): share src IP cache across UDP sockets (#9976)
When looking through customer logs, we see a lot of "Resolved best route outside of tunnel" messages. Those get logged every time we need to rerun our re-implementation of Windows' weighting algorithm as to which source interface / IP a packet should be sent from. Currently, this gets cached in every socket instance so for the peer-to-peer socket, this is only computed once per destination IP. However, for DNS queries, we make a new socket for every query. Using a new source port DNS queries is recommended to avoid fingerprinting of DNS queries. Using a new socket also means that we need to re-run this algorithm every time we make a DNS query which is why we see this log so often. To fix this, we need to share this cache across all UDP sockets. Cache invalidation is one of the hardest problems in computer science and this instance is no different. This cache needs to be reset every time we roam as that changes the weighting of which source interface to use. To achieve this, we extend the `SocketFactory` trait with a `reset` method. This method is called whenever we roam and can then reset a shared cache inside the `UdpSocketFactory`. The "source IP resolver" function that is passed to the UDP socket now simply accesses this shared cache and inserts a new entry when it needs to resolve the IP. As an added benefit, this may speed up DNS queries on Windows a bit (although I haven't benchmarked it). It should certainly drastically reduce the amount of syscalls we make on Windows. |
||
|
|
409459f11c |
chore(rust): bump boringtun (#9982)
Bumping the version to include https://github.com/firezone/boringtun/pull/105. |
||
|
|
d244a99c58 |
feat(connlib): always use all candidates (#9979)
In #6876, we added functionality that would only make use of new remote candidates whilst we haven't nominated a socket yet with the remote. The reason for that was because in the described edge-case where relays reboot or get replaced whilst the client is partitioned from the portal (or we experience a connection hiccup), only one of the two peers, i.e. Client or Gateway would migrate to the new relay, leaving the other one in an inconsistent state. Looking at recent customer logs, I've been seeing a lot of these messages: > Unknown connection or socket has already been nominated For this particular customer, these are then very quickly followed by ICE timeouts, leaving the connection unusable. Considering that, I no longer think that the above change was a good idea and we should instead always make use of all candidates that we are given. What we are seeing is that in deployment scenarios where the latency link between Client and Gateway is very short (5-10ms) yet the latency to the portal is longer (~30-50ms), we trigger a race condition where we are temporarily nominating a _peer-reflexive_ candidate pair instead of a regular one. This happens because with such a short latency link, Client and Gateway are _faster_ in sending back and forth several STUN bindings than the control plane is in delivering all the candidates. Due to the functionality added in #6876, this then results in us not accepting the candidates. It further appears that a nominated peer-reflexive candidate does not provide a stable connection which is why we then run into an ICE timeout, requiring Firezone to establish a new connection only to have the same thing happen again. This is very disruptive for the user experience as the connection only works for a few moments at a time. With #9793, we have actually added a feature that is also at play here. Now that we don't immediately act on an ICE timeout, it is actually possible for both Client and Gateway to migrate a connection to a different relay, should the one that they are using get disconnected. In #9793, we added a timeout of 2s for this. To make this fully work, we need to patch str0m to transition to `Checking` early. Presently, str0m would directly transition from `Disconnected` to `Connected` in this case which in some of the high-latency scenarios that we are testing in CI is not enough to recover the connection within 2s. By transitioning to `Checking` early, we abort this timer. Related: https://github.com/algesten/str0m/pull/676 |
||
|
|
ecb2bbc86b |
feat(gateway): allow updating expiry of access authorization (#9973)
Resolves: #9966 |
||
|
|
fafe2c43ea |
fix(connlib): update the current socket when in idle mode (#9977)
In case we received a newly nominated socket from `str0m` whilst our connection was in idle mode, we mistakenly did not apply that and kept using the old one. ICE would still be functioning in this case because `str0m` would have updated its internal state but we would be sending packets into Nirvana. I don't think that this is likely to be hit in production though as it would be quite unusual to receive a new nomination whilst the connection was completely idle. |
||
|
|
091d5b56e0 |
refactor(snownet): don't memmove every packet (#9907)
When encrypting IP packets, `snownet` needs to prepare a buffer where the encrypted packet is going to end up. Depending on whether we are sending data via a relayed connection or direct, this buffer needs to be offset by 4 bytes to allow for the 4-byte channel-data header of the TURN protocol. At present, we always first encrypt the packet and then on-demand move the packet by 4-bytes to the left if we **don't** need to send it via a relay. Internally, this translates to a `memmove` instruction which actually turns out to be very cheap (I couldn't measure a speed difference between this and `main`). All of this code has grown historically though so I figured, it is better to clean it up a bit to first evaluate, whether we have a direct or relayed connection and based on that, write the encrypted packet directly to the front of the buffer or offset it by 4 bytes. |
||
|
|
3e6fc8fda7 |
refactor(rust): use spinlock-based buffer pool (#9951)
Profiling has shown that using a spinlock-based buffer pool is marginally (~1%) faster than the mutex-based one because it resolves contention quicker. |
||
|
|
86954a4f4a |
fix(ci): don't version images until release (#9968)
Fixes #9967 |
||
|
|
a11983e4b3 | chore: publish gateway 1.4.13 (#9969) | ||
|
|
6ae074005f |
refactor(connlib): don't check for enabled event (#9950)
Profiling has shown that checking whether the level is enabled is actually more expensive than checking whether the packet is a DNS packet. This improves performance by about 3%. |
||
|
|
71e6b56654 |
feat(snownet): remove "connection ID" span (#9949)
At present, `snownet` uses a `tracing::Span` to attach the connection ID to various log messages. This requires the span to be entered and exited on every packet. Whilst profiling Firezone, I noticed that is takes between 10% and 20% of CPU time on the main thread. Previously, this wasn't a bottleneck as other parts of Firezone were not yet as optimised. With some changes earlier this year of a dedicated UDP thread and better GSO, this does appear to be a bottleneck now. On `main`, I am currently getting the following numbers on my local machine: ``` Connecting to host 172.20.0.110, port 5201 [ 5] local 100.85.16.226 port 42012 connected to 172.20.0.110 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 251 MBytes 2.11 Gbits/sec 16 558 KBytes [ 5] 1.00-2.00 sec 287 MBytes 2.41 Gbits/sec 6 800 KBytes [ 5] 2.00-3.00 sec 284 MBytes 2.38 Gbits/sec 2 992 KBytes [ 5] 3.00-4.00 sec 287 MBytes 2.41 Gbits/sec 3 1.12 MBytes [ 5] 4.00-5.00 sec 290 MBytes 2.44 Gbits/sec 0 1.27 MBytes [ 5] 5.00-6.00 sec 300 MBytes 2.52 Gbits/sec 2 1.40 MBytes [ 5] 6.00-7.00 sec 295 MBytes 2.47 Gbits/sec 2 1.52 MBytes [ 5] 7.00-8.00 sec 304 MBytes 2.55 Gbits/sec 3 1.63 MBytes [ 5] 8.00-9.00 sec 290 MBytes 2.44 Gbits/sec 49 1.21 MBytes [ 5] 9.00-10.00 sec 288 MBytes 2.41 Gbits/sec 24 1023 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 2.81 GBytes 2.41 Gbits/sec 107 sender [ 5] 0.00-10.00 sec 2.81 GBytes 2.41 Gbits/sec receiver ``` With this patch applied, the throughput goes up significantly: ``` Connecting to host 172.20.0.110, port 5201 [ 5] local 100.85.16.226 port 41402 connected to 172.20.0.110 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 315 MBytes 2.64 Gbits/sec 7 619 KBytes [ 5] 1.00-2.00 sec 363 MBytes 3.05 Gbits/sec 11 847 KBytes [ 5] 2.00-3.00 sec 379 MBytes 3.18 Gbits/sec 1 1.07 MBytes [ 5] 3.00-4.00 sec 384 MBytes 3.22 Gbits/sec 44 981 KBytes [ 5] 4.00-5.00 sec 377 MBytes 3.16 Gbits/sec 116 911 KBytes [ 5] 5.00-6.00 sec 378 MBytes 3.17 Gbits/sec 3 1.10 MBytes [ 5] 6.00-7.00 sec 377 MBytes 3.16 Gbits/sec 48 929 KBytes [ 5] 7.00-8.00 sec 374 MBytes 3.14 Gbits/sec 151 947 KBytes [ 5] 8.00-9.00 sec 382 MBytes 3.21 Gbits/sec 36 833 KBytes [ 5] 9.00-10.00 sec 375 MBytes 3.14 Gbits/sec 1 1.06 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 3.62 GBytes 3.11 Gbits/sec 418 sender [ 5] 0.00-10.00 sec 3.61 GBytes 3.10 Gbits/sec receiver ``` Resolves: #9948 |
||
|
|
f41a6f9e0b |
fix(portal): don't use process.alive on remote pid (#9964)
This can be removed, since we handle the ArgumentError in the link operation. |
||
|
|
2c3692582b |
fix(portal): more robust replication pid discovery (#9960)
When debugging why we're receiving "Failed to start replication
connection" errors on deploy, it was discovered that there's a bug in
the Process discovery mechanism that new nodes use to attempt to link to
the existing replication connection. When restarting an existing
`domain` container that's not doing replication, we see this:
```
{"message":"Elixir.Domain.Events.ReplicationConnection: Publication tables are up to date","time":"2025-07-22T07:18:45.948Z","domain":["elixir"],"application":"domain","severity":"INFO","logging.googleapis.com/sourceLocation":{"function":"Elixir.Domain.Events.ReplicationConnection.handle_publication_tables_diff/2","line":2,"file":"lib/domain/events/replication_connection.ex"},"logging.googleapis.com/operation":{"producer":"#PID<0.764.0>"}}
{"message":"notifier only receiving messages from its own node, functionality may be degraded","time":"2025-07-22T07:18:45.942Z","domain":["elixir"],"application":"oban","source":"oban","severity":"DEBUG","event":"notifier:switch","connectivity_status":"solitary","logging.googleapis.com/sourceLocation":{"function":"Elixir.Oban.Telemetry.log/2","line":624,"file":"lib/oban/telemetry.ex"},"logging.googleapis.com/operation":{"producer":"#PID<0.756.0>"}}
{"message":"Elixir.Domain.ChangeLogs.ReplicationConnection: Publication tables are up to date","time":"2025-07-22T07:18:45.952Z","domain":["elixir"],"application":"domain","severity":"INFO","logging.googleapis.com/sourceLocation":{"function":"Elixir.Domain.ChangeLogs.ReplicationConnection.handle_publication_tables_diff/2","line":2,"file":"lib/domain/change_logs/replication_connection.ex"},"logging.googleapis.com/operation":{"producer":"#PID<0.763.0>"}}
{"message":"Elixir.Domain.ChangeLogs.ReplicationConnection: Starting replication slot change_logs_slot","time":"2025-07-22T07:18:45.966Z","state":"[REDACTED]","domain":["elixir"],"application":"domain","severity":"INFO","logging.googleapis.com/sourceLocation":{"function":"Elixir.Domain.ChangeLogs.ReplicationConnection.handle_result/2","line":2,"file":"lib/domain/change_logs/replication_connection.ex"},"logging.googleapis.com/operation":{"producer":"#PID<0.763.0>"}}
{"message":"Elixir.Domain.Events.ReplicationConnection: Starting replication slot events_slot","time":"2025-07-22T07:18:45.966Z","state":"[REDACTED]","domain":["elixir"],"application":"domain","severity":"INFO","logging.googleapis.com/sourceLocation":{"function":"Elixir.Domain.Events.ReplicationConnection.handle_result/2","line":2,"file":"lib/domain/events/replication_connection.ex"},"logging.googleapis.com/operation":{"producer":"#PID<0.764.0>"}}
{"message":"Elixir.Domain.ChangeLogs.ReplicationConnection: Replication connection disconnected","time":"2025-07-22T07:18:45.977Z","domain":["elixir"],"application":"domain","counter":0,"severity":"INFO","logging.googleapis.com/sourceLocation":{"function":"Elixir.Domain.ChangeLogs.ReplicationConnection.handle_disconnect/1","line":2,"file":"lib/domain/change_logs/replication_connection.ex"},"logging.googleapis.com/operation":{"producer":"#PID<0.763.0>"}}
{"message":"Elixir.Domain.Events.ReplicationConnection: Replication connection disconnected","time":"2025-07-22T07:18:45.977Z","domain":["elixir"],"application":"domain","counter":0,"severity":"INFO","logging.googleapis.com/sourceLocation":{"function":"Elixir.Domain.Events.ReplicationConnection.handle_disconnect/1","line":2,"file":"lib/domain/events/replication_connection.ex"},"logging.googleapis.com/operation":{"producer":"#PID<0.764.0>"}}
{"message":"Failed to start replication connection Elixir.Domain.Events.ReplicationConnection","reason":"%Postgrex.Error{message: nil, postgres: %{code: :object_in_use, line: \"607\", message: \"replication slot \\\"events_slot\\\" is active for PID 135123\", file: \"slot.c\", unknown: \"ERROR\", severity: \"ERROR\", pg_code: \"55006\", routine: \"ReplicationSlotAcquire\"}, connection_id: 136400, query: nil}","time":"2025-07-22T07:18:45.978Z","domain":["elixir"],"application":"domain","max_retries":10,"severity":"INFO","logging.googleapis.com/sourceLocation":{"function":"Elixir.Domain.Replication.Manager.handle_info/2","line":41,"file":"lib/domain/replication/manager.ex"},"logging.googleapis.com/operation":{"producer":"#PID<0.761.0>"},"retries":0}
{"message":"Failed to start replication connection Elixir.Domain.ChangeLogs.ReplicationConnection","reason":"%Postgrex.Error{message: nil, postgres: %{code: :object_in_use, line: \"607\", message: \"replication slot \\\"change_logs_slot\\\" is active for PID 135124\", file: \"slot.c\", unknown: \"ERROR\", severity: \"ERROR\", pg_code: \"55006\", routine: \"ReplicationSlotAcquire\"}, connection_id: 136401, query: nil}","time":"2025-07-22T07:18:45.978Z","domain":["elixir"],"application":"domain","max_retries":10,"severity":"INFO","logging.googleapis.com/sourceLocation":{"function":"Elixir.Domain.Replication.Manager.handle_info/2","line":41,"file":"lib/domain/replication/manager.ex"},"logging.googleapis.com/operation":{"producer":"#PID<0.760.0>"},"retries":0}
```
Before, we relied on `start_link` telling us that there was an existing
pid running in the cluster. However, from the output above, it appears
that may not always be reliable.
Instead, we first check explicitly where the running process is and, if
alive, we try linking to it. If not, we try starting the connection
ourselves.
Once linked to the process, we react to it being torn down as well,
causing a first-one-wins scenario where all nodes will attempt to start
replication, minimizing downtime during deploys.
Now that https://github.com/firezone/infra/pull/94 is in place, I did
verify we are properly handling SIGTERM in the BEAM, so the deployment
would now go like this:
1. GCP brings up the new nodes, they all find the existing pid and link
to it
2. GCP sends SIGTERM to the old nodes
3. The _actual_ pid receives SIGTERM and exits
4. This exit propagates to all other nodes due to the link
5. Some node will "win", and the others will end up linking to it
Fixes #9911
|
||
|
|
4292ca7ae8 |
test(connlib): fix failing proptest (#9864)
This essentially bumps just the boringtun dependency to include https://github.com/firezone/boringtun/pull/104. |
||
|
|
fbf96c261e |
chore(relay): remove spans (#9962)
These are flooding our monitoring infra and don't really add that much value. Pretty much all of the processing the relay does is request in and out and none of the spans are nested. We can therefore almost 1-to-1 replicate the logging we do with spans by adding the fields to each log message. Resolves: #9954 |
||
|
|
4c0c605c72 |
build(deps): bump taiki-e/install-action from 2.55.3 to 2.56.19 (#9918)
Bumps [taiki-e/install-action](https://github.com/taiki-e/install-action) from 2.55.3 to 2.56.19. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's releases</a>.</em></p> <blockquote> <h2>2.56.19</h2> <ul> <li>Update <code>cargo-llvm-cov@latest</code> to 0.6.18.</li> </ul> <h2>2.56.18</h2> <ul> <li>Update <code>just@latest</code> to 1.42.3.</li> </ul> <h2>2.56.17</h2> <ul> <li>Update <code>wasmtime@latest</code> to 34.0.2.</li> </ul> <h2>2.56.16</h2> <ul> <li> <p>Update <code>cargo-zigbuild@latest</code> to 0.20.1.</p> </li> <li> <p>Update <code>cargo-lambda@latest</code> to 1.8.6.</p> </li> <li> <p>Update <code>vacuum@latest</code> to 0.17.6.</p> </li> <li> <p>Update <code>earthly@latest</code> to 0.8.16.</p> </li> </ul> <h2>2.56.15</h2> <ul> <li> <p>Fix <code>cargo-valgrind</code> installation error due to their tag rename.</p> </li> <li> <p>Update <code>cargo-valgrind@latest</code> to 2.3.2.</p> </li> <li> <p>Update <code>just@latest</code> to 1.42.2.</p> </li> </ul> <h2>2.56.14</h2> <ul> <li> <p>Update <code>zola@latest</code> to 0.21.0.</p> </li> <li> <p>Update <code>wait-for-them@latest</code> to 0.5.1.</p> </li> <li> <p>Update <code>mdbook@latest</code> to 0.4.52.</p> </li> <li> <p>Update <code>just@latest</code> to 1.42.1.</p> </li> <li> <p>Update <code>cargo-shear@latest</code> to 1.4.0.</p> </li> <li> <p>Update <code>cyclonedx@latest</code> to 0.29.0.</p> </li> </ul> <h2>2.56.13</h2> <ul> <li>Update <code>cargo-nextest@latest</code> to 0.9.101.</li> </ul> <h2>2.56.12</h2> <ul> <li>Update <code>cargo-hack@latest</code> to 0.6.37.</li> </ul> <h2>2.56.11</h2> <ul> <li> <p>Update <code>osv-scanner@latest</code> to 2.1.0.</p> </li> <li> <p>Update <code>cargo-no-dev-deps@latest</code> to 0.2.16.</p> </li> <li> <p>Update <code>cargo-minimal-versions@latest</code> to 0.1.31.</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's changelog</a>.</em></p> <blockquote> <h1>Changelog</h1> <p>All notable changes to this project will be documented in this file.</p> <p>This project adheres to <a href="https://semver.org">Semantic Versioning</a>.</p> <!-- raw HTML omitted --> <h2>[Unreleased]</h2> <h2>[2.56.19] - 2025-07-19</h2> <ul> <li>Update <code>cargo-llvm-cov@latest</code> to 0.6.18.</li> </ul> <h2>[2.56.18] - 2025-07-19</h2> <ul> <li>Update <code>just@latest</code> to 1.42.3.</li> </ul> <h2>[2.56.17] - 2025-07-18</h2> <ul> <li>Update <code>wasmtime@latest</code> to 34.0.2.</li> </ul> <h2>[2.56.16] - 2025-07-18</h2> <ul> <li> <p>Update <code>cargo-zigbuild@latest</code> to 0.20.1.</p> </li> <li> <p>Update <code>cargo-lambda@latest</code> to 1.8.6.</p> </li> <li> <p>Update <code>vacuum@latest</code> to 0.17.6.</p> </li> <li> <p>Update <code>earthly@latest</code> to 0.8.16.</p> </li> </ul> <h2>[2.56.15] - 2025-07-16</h2> <ul> <li> <p>Fix <code>cargo-valgrind</code> installation error due to their tag rename.</p> </li> <li> <p>Update <code>cargo-valgrind@latest</code> to 2.3.2.</p> </li> <li> <p>Update <code>just@latest</code> to 1.42.2.</p> </li> </ul> <h2>[2.56.14] - 2025-07-15</h2> <ul> <li> <p>Update <code>zola@latest</code> to 0.21.0.</p> </li> <li> <p>Update <code>wait-for-them@latest</code> to 0.5.1.</p> </li> <li> <p>Update <code>mdbook@latest</code> to 0.4.52.</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
f668202c83 |
build(deps): bump the sentry group in /rust/gui-client with 2 updates (#9929)
Bumps the sentry group in /rust/gui-client with 2 updates: [@sentry/core](https://github.com/getsentry/sentry-javascript) and [@sentry/react](https://github.com/getsentry/sentry-javascript). Updates `@sentry/core` from 9.34.0 to 9.40.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/getsentry/sentry-javascript/releases"><code>@sentry/core</code>'s releases</a>.</em></p> <blockquote> <h2>9.40.0</h2> <h3>Important Changes</h3> <ul> <li><strong>feat(browser): Add debugId sync APIs between web worker and main thread (<a href="https://redirect.github.com/getsentry/sentry-javascript/pull/16981">#16981</a>)</strong></li> </ul> <p>This release adds two Browser SDK APIs to let the main thread know about debugIds of worker files:</p> <ul> <li><code>webWorkerIntegration({worker})</code> to be used in the main thread</li> <li><code>registerWebWorker({self})</code> to be used in the web worker</li> </ul> <pre lang="js"><code>// main.js Sentry.init({...}) <p>const worker = new MyWorker(...);</p> <p>Sentry.addIntegration(Sentry.webWorkerIntegration({ worker }));</p> <p>worker.addEventListener('message', e => {...});<br /> </code></pre></p> <pre lang="js"><code>// worker.js Sentry.registerWebWorker({ self }); self.postMessage(...); </code></pre> <ul> <li><strong>feat(core): Deprecate logger in favor of debug (<a href="https://redirect.github.com/getsentry/sentry-javascript/pull/17040">#17040</a>)</strong></li> </ul> <p>The internal SDK <code>logger</code> export from <code>@sentry/core</code> has been deprecated in favor of the <code>debug</code> export. <code>debug</code> only exposes <code>log</code>, <code>warn</code>, and <code>error</code> methods but is otherwise identical to <code>logger</code>. Note that this deprecation does not affect the <code>logger</code> export from other packages (like <code>@sentry/browser</code> or <code>@sentry/node</code>) which is used for Sentry Logging.</p> <pre lang="js"><code>import { logger, debug } from '@sentry/core'; <p>// before<br /> logger.info('This is an info message');</p> <p>// after<br /> debug.log('This is an info message');<br /> </code></pre></p> <ul> <li><strong>feat(node): Add OpenAI integration (<a href="https://redirect.github.com/getsentry/sentry-javascript/pull/17022">#17022</a>)</strong></li> </ul> <p>This release adds official support for instrumenting OpenAI SDK calls in with Sentry tracing, following OpenTelemetry semantic conventions for Generative AI. It instruments:</p> <ul> <li><code>client.chat.completions.create()</code> - For chat-based completions</li> <li><code>client.responses.create()</code> - For the responses API</li> </ul> <pre lang="js"><code></tr></table> </code></pre> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/getsentry/sentry-javascript/blob/develop/CHANGELOG.md"><code>@sentry/core</code>'s changelog</a>.</em></p> <blockquote> <h2>9.40.0</h2> <h3>Important Changes</h3> <ul> <li><strong>feat(browser): Add debugId sync APIs between web worker and main thread (<a href="https://redirect.github.com/getsentry/sentry-javascript/pull/16981">#16981</a>)</strong></li> </ul> <p>This release adds two Browser SDK APIs to let the main thread know about debugIds of worker files:</p> <ul> <li><code>webWorkerIntegration({worker})</code> to be used in the main thread</li> <li><code>registerWebWorker({self})</code> to be used in the web worker</li> </ul> <pre lang="js"><code>// main.js Sentry.init({...}) <p>const worker = new MyWorker(...);</p> <p>Sentry.addIntegration(Sentry.webWorkerIntegration({ worker }));</p> <p>worker.addEventListener('message', e => {...});<br /> </code></pre></p> <pre lang="js"><code>// worker.js Sentry.registerWebWorker({ self }); self.postMessage(...); </code></pre> <ul> <li><strong>feat(core): Deprecate logger in favor of debug (<a href="https://redirect.github.com/getsentry/sentry-javascript/pull/17040">#17040</a>)</strong></li> </ul> <p>The internal SDK <code>logger</code> export from <code>@sentry/core</code> has been deprecated in favor of the <code>debug</code> export. <code>debug</code> only exposes <code>log</code>, <code>warn</code>, and <code>error</code> methods but is otherwise identical to <code>logger</code>. Note that this deprecation does not affect the <code>logger</code> export from other packages (like <code>@sentry/browser</code> or <code>@sentry/node</code>) which is used for Sentry Logging.</p> <pre lang="js"><code>import { logger, debug } from '@sentry/core'; <p>// before<br /> logger.info('This is an info message');</p> <p>// after<br /> debug.log('This is an info message');<br /> </code></pre></p> <ul> <li><strong>feat(node): Add OpenAI integration (<a href="https://redirect.github.com/getsentry/sentry-javascript/pull/17022">#17022</a>)</strong></li> </ul> <p>This release adds official support for instrumenting OpenAI SDK calls in with Sentry tracing, following OpenTelemetry semantic conventions for Generative AI. It instruments:</p> <ul> <li><code>client.chat.completions.create()</code> - For chat-based completions</li> <li><code>client.responses.create()</code> - For the responses API</li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
2392bddacb |
fix(elixir): handle nil external url config in dev mode (#9958)
This is nil in local dev. Fixing this allows us to run the local dev in `:prod` mode to hit more codepaths. |
||
|
|
b631b9a59e | docs(windows): improve troubleshooting instructions (#9959) | ||
|
|
e4ba5a6929 |
fix(portal): inherit pid 1 in cmd (#9957)
Apparently using the shell form of this causes it not to inherit PID 1 from tini. |
||
|
|
0a0ee3c940 |
build(deps): bump sentry from 10.10.0 to 11.0.2 in /elixir (#9933)
Bumps [sentry](https://github.com/getsentry/sentry-elixir) from 10.10.0 to 11.0.2. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/getsentry/sentry-elixir/releases">sentry's releases</a>.</em></p> <blockquote> <h2>11.0.2</h2> <h3>Bug fixes</h3> <ul> <li>Deeply nested spans are handled now when building up traces in <code>SpanProcessor</code> (<a href="https://redirect.github.com/getsentry/sentry-elixir/pull/924">#924</a>)</li> </ul> <h4>Various improvements</h4> <ul> <li>Span's attributes no longer include <code>db.url: "ecto:"</code> entries as they are now filtered out (<a href="https://redirect.github.com/getsentry/sentry-elixir/pull/925">#925</a>)</li> </ul> <h2>11.0.1</h2> <h4>Various improvements</h4> <ul> <li><code>Sentry.OpenTelemetry.Sampler</code> now works with an empty config (<a href="https://redirect.github.com/getsentry/sentry-elixir/pull/915">#915</a>)</li> </ul> <h2>11.0.0</h2> <p>This release comes with a beta support for Traces using OpenTelemetry - please test it out and report any issues you find.</p> <h3>New features</h3> <ul> <li> <p>Beta support for Traces using OpenTelemetry (<a href="https://redirect.github.com/getsentry/sentry-elixir/pull/902">#902</a>)</p> <p>To enable Tracing in your Phoenix application, you need to add the following to your <code>mix.exs</code>:</p> <pre lang="elixir"><code>def deps do [ # ... {:sentry, "~> 11.0.0"}, {:opentelemetry, "~> 1.5"}, {:opentelemetry_api, "~> 1.4"}, {:opentelemetry_exporter, "~> 1.0"}, {:opentelemetry_semantic_conventions, "~> 1.27"}, {:opentelemetry_phoenix, "~> 2.0"}, {:opentelemetry_ecto, "~> 1.2"}, # ... ] </code></pre> <p>And then configure Tracing in Sentry and OpenTelemetry in your <code>config.exs</code>:</p> <pre lang="elixir"><code>config :sentry, # ... traces_sample_rate: 1.0 # any value between 0 and 1.0 enables tracing <p>config :opentelemetry, span_processor: {Sentry.OpenTelemetry.SpanProcessor, []} config :opentelemetry, sampler: {Sentry.OpenTelemetry.Sampler, [drop: []]} </code></pre></p> </li> <li> <p>Add installer (based on Igniter) (<a href="https://redirect.github.com/getsentry/sentry-elixir/pull/876">#876</a>)</p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/getsentry/sentry-elixir/blob/master/CHANGELOG.md">sentry's changelog</a>.</em></p> <blockquote> <h2>11.0.2</h2> <h3>Bug fixes</h3> <ul> <li>Deeply nested spans are handled now when building up traces in <code>SpanProcessor</code> (<a href="https://redirect.github.com/getsentry/sentry-elixir/pull/924">#924</a>)</li> </ul> <h4>Various improvements</h4> <ul> <li>Span's attributes no longer include <code>db.url: "ecto:"</code> entries as they are now filtered out (<a href="https://redirect.github.com/getsentry/sentry-elixir/pull/925">#925</a>)</li> </ul> <h2>11.0.1</h2> <h4>Various improvements</h4> <ul> <li><code>Sentry.OpenTelemetry.Sampler</code> now works with an empty config (<a href="https://redirect.github.com/getsentry/sentry-elixir/pull/915">#915</a>)</li> </ul> <h2>11.0.0</h2> <p>This release comes with a beta support for Traces using OpenTelemetry - please test it out and report any issues you find.</p> <h3>New features</h3> <ul> <li> <p>Beta support for Traces using OpenTelemetry (<a href="https://redirect.github.com/getsentry/sentry-elixir/pull/902">#902</a>)</p> <p>To enable Tracing in your Phoenix application, you need to add the following to your <code>mix.exs</code>:</p> <pre lang="elixir"><code>def deps do [ # ... {:sentry, "~> 11.0.0"}, {:opentelemetry, "~> 1.5"}, {:opentelemetry_api, "~> 1.4"}, {:opentelemetry_exporter, "~> 1.0"}, {:opentelemetry_semantic_conventions, "~> 1.27"}, {:opentelemetry_phoenix, "~> 2.0"}, {:opentelemetry_ecto, "~> 1.2"}, # ... ] </code></pre> <p>And then configure Tracing in Sentry and OpenTelemetry in your <code>config.exs</code>:</p> <pre lang="elixir"><code>config :sentry, # ... traces_sample_rate: 1.0 # any value between 0 and 1.0 enables tracing <p>config :opentelemetry, span_processor: {Sentry.OpenTelemetry.SpanProcessor, []} config :opentelemetry, sampler: {Sentry.OpenTelemetry.Sampler, []} </code></pre></p> </li> </ul> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
1b1bd6401a |
fix(portal): gracefully account deletions in changelog (#9955)
When an account is perma-deleted, we need to handle that with another function clause matching the WAL message coming into the change logs replication connection module. |
||
|
|
488cb96469 |
fix(portal): don't prematurely reject access (#9952)
Before:
- When a flow was deleted, we flapped the resource on the client, and
sent `reject_access` naively for the flow's `{client_id, resource_id}`
pair on the gateway. This resulted in lots of unneeded resource flappage
on the client whenever bulk flow deletions happened.
After:
- When a flow is deleted, we check if this is an active flow for the
client. If so, we flap the resource then in order to trigger generation
of a new flow. If access was truly affected, that results in a loss of a
resource, we will push `resource_deleted` for the update that triggered
the flow deletion (for example the resource/policy removal). On the
gateway, we only send `reject_access` if it was the last flow granting
access for a particular `client/resource` tuple.
Why:
- While the access state is still correct in the previous
implementation, we run the possibility of pushing way too many resource
flaps to the client in an overly eager attempt to remove access the
client may not have access to.
cc @thomaseizinger
Related:
https://firezonehq.slack.com/archives/C08FPHECLUF/p1753101115735179
|
||
|
|
dff6495057 | fix(ci): use pinned musl toolchains (#9953) | ||
|
|
272074e8d4 |
build(deps): bump hammer from 7.0.1 to 7.1.0 in /elixir (#9935)
Bumps [hammer](https://github.com/ExHammer/hammer) from 7.0.1 to 7.1.0. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/ExHammer/hammer/blob/master/CHANGELOG.md">hammer's changelog</a>.</em></p> <blockquote> <h2>7.1.0 - 2025-07-18</h2> <ul> <li>Fix key type inconsistency in backend implementations - all backends now accept <code>term()</code> keys instead of <code>String.t()</code> (<a href="https://redirect.github.com/ExHammer/hammer/issues/143">#143</a>)</li> <li>Add comprehensive test coverage for various key types (atoms, tuples, integers, lists, maps)</li> <li>Fix race conditions in atomic backend tests (FixWindow, LeakyBucket, TokenBucket)</li> <li>Replace timing-dependent tests with polling-based <code>eventually</code> helper for better CI reliability</li> <li>Add documentation warning about Redis backend string key requirement</li> <li>Fix typo in <code>inc/3</code> optional callback documentation (<a href="https://redirect.github.com/ExHammer/hammer/issues/142">#142</a>)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
619cfa0a37 |
build(deps): bump telemetry_poller from 1.2.0 to 1.3.0 in /elixir (#9917)
Bumps [telemetry_poller](https://github.com/beam-telemetry/telemetry_poller) from 1.2.0 to 1.3.0. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/beam-telemetry/telemetry_poller/blob/main/CHANGELOG.md">telemetry_poller's changelog</a>.</em></p> <blockquote> <h2><a href="https://github.com/beam-telemetry/telemetry_poller/tree/v1.3.0">1.3.0</a></h2> <h3>Added</h3> <ul> <li>Add <code>atom_limit</code>, <code>process_limit</code>, and <code>port_limit</code> measurements to the <code>[vm, system_counts]</code> event. (<a href="https://redirect.github.com/beam-telemetry/telemetry_poller/issues/79">#79</a>)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
bc1a3df82b |
build(deps): bump react-router from 7.6.3 to 7.7.0 in /rust/gui-client in the react group (#9934)
Bumps the react group in /rust/gui-client with 1 update: [react-router](https://github.com/remix-run/react-router/tree/HEAD/packages/react-router). Updates `react-router` from 7.6.3 to 7.7.0 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/remix-run/react-router/releases">react-router's releases</a>.</em></p> <blockquote> <h2>v7.7.0</h2> <p>See the changelog for release notes: <a href="https://github.com/remix-run/react-router/blob/main/CHANGELOG.md#v770">https://github.com/remix-run/react-router/blob/main/CHANGELOG.md#v770</a></p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/remix-run/react-router/blob/main/packages/react-router/CHANGELOG.md">react-router's changelog</a>.</em></p> <blockquote> <h2>7.7.0</h2> <h3>Minor Changes</h3> <ul> <li> <p>Add unstable RSC support (<a href="https://redirect.github.com/remix-run/react-router/pull/13700">#13700</a>)</p> <p>For more information, see the <a href="https://reactrouter.com/start/rsc/installation">RSC documentation</a>.</p> </li> </ul> <h3>Patch Changes</h3> <ul> <li> <p>Handle <code>InvalidCharacterError</code> when validating cookie signature (<a href="https://redirect.github.com/remix-run/react-router/pull/13847">#13847</a>)</p> </li> <li> <p>Pass a copy of <code>searchParams</code> to the <code>setSearchParams</code> callback function to avoid muations of the internal <code>searchParams</code> instance. This was an issue when navigations were blocked because the internal instance be out of sync with <code>useLocation().search</code>. (<a href="https://redirect.github.com/remix-run/react-router/pull/12784">#12784</a>)</p> </li> <li> <p>Support invalid <code>Date</code> in <code>turbo-stream</code> v2 fork (<a href="https://redirect.github.com/remix-run/react-router/pull/13684">#13684</a>)</p> </li> <li> <p>In Framework Mode, clear critical CSS in development after initial render (<a href="https://redirect.github.com/remix-run/react-router/pull/13872">#13872</a>)</p> </li> <li> <p>Strip search parameters from <code>patchRoutesOnNavigation</code> <code>path</code> param for fetcher calls (<a href="https://redirect.github.com/remix-run/react-router/pull/13911">#13911</a>)</p> </li> <li> <p>Skip scroll restoration on useRevalidator() calls because they're not new locations (<a href="https://redirect.github.com/remix-run/react-router/pull/13671">#13671</a>)</p> </li> <li> <p>Support unencoded UTF-8 routes in prerender config with <code>ssr</code> set to <code>false</code> (<a href="https://redirect.github.com/remix-run/react-router/pull/13699">#13699</a>)</p> </li> <li> <p>Do not throw if the url hash is not a valid URI component (<a href="https://redirect.github.com/remix-run/react-router/pull/13247">#13247</a>)</p> </li> <li> <p>Fix a regression in <code>createRoutesStub</code> introduced with the middleware feature. (<a href="https://redirect.github.com/remix-run/react-router/pull/13946">#13946</a>)</p> <p>As part of that work we altered the signature to align with the new middleware APIs without making it backwards compatible with the prior <code>AppLoadContext</code> API. This permitted <code>createRoutesStub</code> to work if you were opting into middleware and the updated <code>context</code> typings, but broke <code>createRoutesStub</code> for users not yet opting into middleware.</p> <p>We've reverted this change and re-implemented it in such a way that both sets of users can leverage it.</p> <pre lang="tsx"><code>// If you have not opted into middleware, the old API should work again let context: AppLoadContext = { /*...*/ }; let Stub = createRoutesStub(routes, context); <p>// If you have opted into middleware, you should now pass an instantiated <code>unstable_routerContextProvider</code> instead of a <code>getContext</code> factory function.<br /> let context = new unstable_RouterContextProvider();<br /> context.set(SomeContext, someValue);<br /> let Stub = createRoutesStub(routes, context);<br /> </code></pre></p> <p>⚠️ This may be a breaking bug for if you have adopted the unstable Middleware feature and are using <code>createRoutesStub</code> with the updated API.</p> </li> <li> <p>Remove <code>Content-Length</code> header from Single Fetch responses (<a href="https://redirect.github.com/remix-run/react-router/pull/13902">#13902</a>)</p> </li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
0cd4b94691 |
build(deps): bump zbus from 5.8.0 to 5.9.0 in /rust (#9939)
Bumps [zbus](https://github.com/dbus2/zbus) from 5.8.0 to 5.9.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/dbus2/zbus/releases">zbus's releases</a>.</em></p> <blockquote> <h2>🔖 zbus 5.9.0</h2> <ul> <li>🧵 Remove deadlocks in Connection name request tasks, resulting in leaks under certain circumstances.</li> <li>🐛 When registering names, allow name replacement by default.</li> <li>✨ Allow setting request name flags in <code>connection::Builder</code>.</li> <li>✨ Proper Default impl for <code>RequestNameFlags</code>. This change is theoretically an API break for users who assumed the default value to be empty.</li> <li>🧑💻 Add <code>fdo::StartServiceReply</code> type. In 6.0 this will be the return type of <code>fdo::DBusProxy::start_service_by_name</code>. For now, just provide a <code>TryFrom<u32></code>.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
8925d70ae1 |
build(deps): bump the lifecycle group in /kotlin/android with 3 updates (#9919)
Bumps the lifecycle group in /kotlin/android with 3 updates: androidx.lifecycle:lifecycle-runtime-ktx, androidx.lifecycle:lifecycle-viewmodel-ktx and androidx.lifecycle:lifecycle-livedata-ktx. Updates `androidx.lifecycle:lifecycle-runtime-ktx` from 2.9.1 to 2.9.2 Updates `androidx.lifecycle:lifecycle-viewmodel-ktx` from 2.9.1 to 2.9.2 Updates `androidx.lifecycle:lifecycle-livedata-ktx` from 2.9.1 to 2.9.2 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 <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
|
0df8c45f6c |
build(deps): bump serde_json from 1.0.140 to 1.0.141 in /rust (#9938)
Bumps [serde_json](https://github.com/serde-rs/json) from 1.0.140 to 1.0.141. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/serde-rs/json/releases">serde_json's releases</a>.</em></p> <blockquote> <h2>v1.0.141</h2> <ul> <li>Optimize string escaping during serialization (<a href="https://redirect.github.com/serde-rs/json/issues/1273">#1273</a>, thanks <a href="https://github.com/conradludgate"><code>@conradludgate</code></a>)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
bba4ebe0da |
build(deps): bump eslint from 9.29.0 to 9.31.0 in /rust/gui-client (#9936)
Bumps [eslint](https://github.com/eslint/eslint) from 9.29.0 to 9.31.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/eslint/eslint/releases">eslint's releases</a>.</em></p> <blockquote> <h2>v9.31.0</h2> <h2>Features</h2> <ul> <li><a href=" |
||
|
|
09f64a6c1e |
build(deps): bump the navigation group in /kotlin/android with 4 updates (#9922)
Bumps the navigation group in /kotlin/android with 4 updates: androidx.navigation:navigation-safe-args-gradle-plugin, androidx.navigation:navigation-fragment-ktx, androidx.navigation:navigation-ui-ktx and androidx.navigation:navigation-testing. Updates `androidx.navigation:navigation-safe-args-gradle-plugin` from 2.9.0 to 2.9.2 Updates `androidx.navigation:navigation-fragment-ktx` from 2.9.0 to 2.9.2 Updates `androidx.navigation:navigation-ui-ktx` from 2.9.0 to 2.9.2 Updates `androidx.navigation:navigation-testing` from 2.9.0 to 2.9.2 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 <dependency name> major version` will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself) - `@dependabot ignore <dependency name> minor version` will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself) - `@dependabot ignore <dependency name>` will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself) - `@dependabot unignore <dependency name>` will remove all of the ignore conditions of the specified dependency - `@dependabot unignore <dependency name> <ignore condition>` will remove the ignore condition of the specified dependency and ignore conditions </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> |
||
|
|
c498d725f4 |
build(deps): bump actions/setup-node from 4.1.0 to 4.4.0 in /.github/actions/setup-node (#9924)
Bumps [actions/setup-node](https://github.com/actions/setup-node) from 4.1.0 to 4.4.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/actions/setup-node/releases">actions/setup-node's releases</a>.</em></p> <blockquote> <h2>v4.4.0</h2> <h2>What's Changed</h2> <h3>Bug fixes:</h3> <ul> <li>Make eslint-compact matcher compatible with Stylelint by <a href="https://github.com/FloEdelmann"><code>@FloEdelmann</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/98">actions/setup-node#98</a></li> <li>Add support for indented eslint output by <a href="https://github.com/fregante"><code>@fregante</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/1245">actions/setup-node#1245</a></li> </ul> <h3>Enhancement:</h3> <ul> <li>Support private mirrors by <a href="https://github.com/marco-ippolito"><code>@marco-ippolito</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/1240">actions/setup-node#1240</a></li> </ul> <h3>Dependency update:</h3> <ul> <li>Upgrade <code>@action/cache</code> from 4.0.2 to 4.0.3 by <a href="https://github.com/aparnajyothi-y"><code>@aparnajyothi-y</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/1262">actions/setup-node#1262</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/FloEdelmann"><code>@FloEdelmann</code></a> made their first contribution in <a href="https://redirect.github.com/actions/setup-node/pull/98">actions/setup-node#98</a></li> <li><a href="https://github.com/fregante"><code>@fregante</code></a> made their first contribution in <a href="https://redirect.github.com/actions/setup-node/pull/1245">actions/setup-node#1245</a></li> <li><a href="https://github.com/marco-ippolito"><code>@marco-ippolito</code></a> made their first contribution in <a href="https://redirect.github.com/actions/setup-node/pull/1240">actions/setup-node#1240</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/actions/setup-node/compare/v4...v4.4.0">https://github.com/actions/setup-node/compare/v4...v4.4.0</a></p> <h2>v4.3.0</h2> <h2>What's Changed</h2> <h3>Dependency updates</h3> <ul> <li>Upgrade <code>@actions/glob</code> from 0.4.0 to 0.5.0 by <a href="https://github.com/dependabot"><code>@dependabot</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/1200">actions/setup-node#1200</a></li> <li>Upgrade <code>@action/cache</code> from 4.0.0 to 4.0.2 by <a href="https://github.com/gowridurgad"><code>@gowridurgad</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/1251">actions/setup-node#1251</a></li> <li>Upgrade <code>@vercel/ncc</code> from 0.38.1 to 0.38.3 by <a href="https://github.com/dependabot"><code>@dependabot</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/1203">actions/setup-node#1203</a></li> <li>Upgrade <code>@actions/tool-cache</code> from 2.0.1 to 2.0.2 by <a href="https://github.com/dependabot"><code>@dependabot</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/1220">actions/setup-node#1220</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/gowridurgad"><code>@gowridurgad</code></a> made their first contribution in <a href="https://redirect.github.com/actions/setup-node/pull/1251">actions/setup-node#1251</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/actions/setup-node/compare/v4...v4.3.0">https://github.com/actions/setup-node/compare/v4...v4.3.0</a></p> <h2>v4.2.0</h2> <h2>What's Changed</h2> <ul> <li>Enhance workflows and upgrade publish-actions from 0.2.2 to 0.3.0 by <a href="https://github.com/aparnajyothi-y"><code>@aparnajyothi-y</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/1174">actions/setup-node#1174</a></li> <li>Add recommended permissions section to readme by <a href="https://github.com/benwells"><code>@benwells</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/1193">actions/setup-node#1193</a></li> <li>Configure Dependabot settings by <a href="https://github.com/HarithaVattikuti"><code>@HarithaVattikuti</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/1192">actions/setup-node#1192</a></li> <li>Upgrade <code>@actions/cache</code> to <code>^4.0.0</code> by <a href="https://github.com/priyagupta108"><code>@priyagupta108</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/1191">actions/setup-node#1191</a></li> <li>Upgrade pnpm/action-setup from 2 to 4 by <a href="https://github.com/dependabot"><code>@dependabot</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/1194">actions/setup-node#1194</a></li> <li>Upgrade actions/publish-immutable-action from 0.0.3 to 0.0.4 by <a href="https://github.com/dependabot"><code>@dependabot</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/1195">actions/setup-node#1195</a></li> <li>Upgrade semver from 7.6.0 to 7.6.3 by <a href="https://github.com/dependabot"><code>@dependabot</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/1196">actions/setup-node#1196</a></li> <li>Upgrade <code>@types/jest</code> from 29.5.12 to 29.5.14 by <a href="https://github.com/dependabot"><code>@dependabot</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/1201">actions/setup-node#1201</a></li> <li>Upgrade undici from 5.28.4 to 5.28.5 by <a href="https://github.com/dependabot"><code>@dependabot</code></a> in <a href="https://redirect.github.com/actions/setup-node/pull/1205">actions/setup-node#1205</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/benwells"><code>@benwells</code></a> made their first contribution in <a href="https://redirect.github.com/actions/setup-node/pull/1193">actions/setup-node#1193</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/actions/setup-node/compare/v4...v4.2.0">https://github.com/actions/setup-node/compare/v4...v4.2.0</a></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
7832068ab7 |
build(deps): bump the hilt group in /kotlin/android with 4 updates (#9925)
Bumps the hilt group in /kotlin/android with 4 updates: [com.google.dagger.hilt.android](https://github.com/google/dagger), [com.google.dagger:hilt-android](https://github.com/google/dagger), [com.google.dagger:hilt-android-compiler](https://github.com/google/dagger) and [com.google.dagger:hilt-android-testing](https://github.com/google/dagger). Updates `com.google.dagger.hilt.android` from 2.56.2 to 2.57 <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/google/dagger/releases">com.google.dagger.hilt.android's releases</a>.</em></p> <blockquote> <h2>Dagger 2.57</h2> <h1>Potential breaking changes</h1> <p>The generated <code>Factory</code>/<code>MembersInjector</code> constructors have changed from public to private. This shouldn’t affect most users since these classes are only meant to be called by Dagger’s other generated code. If you do happen to be broken by this change, you should avoid calling Dagger’s generated <code>Factory</code>/<code>MembersInjector</code> classes directly. For a temporary solution, you can also switch to using the public static methods to create an instance. (165cf20ee)</p> <h1>Bug fixes</h1> <p>Fixes <a href="https://redirect.github.com/google/dagger/issues/4779">#4779</a>. Unshades the Kotlinx Metadata to support Kotlin 2.2.0 (bfa88b962)</p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
4bb4360792 |
build(deps): bump the okhttp group in /kotlin/android with 2 updates (#9928)
Bumps the okhttp group in /kotlin/android with 2 updates: [com.squareup.okhttp3:okhttp](https://github.com/square/okhttp) and [com.squareup.okhttp3:logging-interceptor](https://github.com/square/okhttp). Updates `com.squareup.okhttp3:okhttp` from 4.12.0 to 5.1.0 <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/square/okhttp/blob/master/CHANGELOG.md">com.squareup.okhttp3:okhttp's changelog</a>.</em></p> <blockquote> <h2>Version 5.1.0</h2> <p><em>2025-07-07</em></p> <ul> <li> <p>New: <code>Response.peekTrailers()</code>. When we changed <code>Response.trailers()</code> to block instead of throwing in 5.0.0, we inadvertently removed the ability for callers to peek the trailers (by catching the <code>IllegalStateException</code> if they weren't available). This new API restores that capability.</p> </li> <li> <p>Fix: Don't crash on <code>trailers()</code> if the response doesn't have a body. We broke [Retrofit] users who read the trailers on the <code>raw()</code> OkHttp response, after its body was decoded.</p> </li> </ul> <h2>Version 5.0.0</h2> <p><em>2025-07-02</em></p> <p>This is our first stable release of OkHttp since 2023. Here's the highlights if you're upgrading from OkHttp 4.x:</p> <p><strong>OkHttp is now packaged as separate JVM and Android artifacts.</strong> This allows us to offer platform-specific features and optimizations. If your build system handles [Gradle module metadata], this change should be automatic.</p> <p><strong>MockWebServer has a new coordinate and package name.</strong> We didn’t like that our old artifact depends on JUnit 4 so the new one doesn’t. It also has a better API built on immutable values. (We intend to continue publishing the old <code>okhttp3.mockwebserver</code> artifact so there’s no urgency to migrate.)</p> <table> <thead> <tr> <th align="left">Coordinate</th> <th align="left">Package Name</th> <th align="left">Description</th> </tr> </thead> <tbody> <tr> <td align="left">com.squareup.okhttp3:mockwebserver3:5.0.0</td> <td align="left">mockwebserver3</td> <td align="left">Core module. No JUnit dependency!</td> </tr> <tr> <td align="left">com.squareup.okhttp3:mockwebserver3-junit4:5.0.0</td> <td align="left">mockwebserver3.junit4</td> <td align="left">Optional JUnit 4 integration.</td> </tr> <tr> <td align="left">com.squareup.okhttp3:mockwebserver3-junit5:5.0.0</td> <td align="left">mockwebserver3.junit5</td> <td align="left">Optional JUnit 5 integration.</td> </tr> <tr> <td align="left">com.squareup.okhttp3:mockwebserver:5.0.0</td> <td align="left">okhttp3.mockwebserver</td> <td align="left">Obsolete. Depends on JUnit 4.</td> </tr> </tbody> </table> <p><strong>OkHttp now supports Happy Eyeballs ([RFC 8305][rfc_8305]) for IPv4+IPv6 networks.</strong> It attempts both IPv6 and IPv4 connections concurrently, keeping whichever connects first.</p> <p><strong>We’ve improved our Kotlin APIs.</strong> You can skip the builder:</p> <pre lang="kotlin"><code>val request = Request( url = "https://cash.app/".toHttpUrl(), ) </code></pre> <p><strong>OkHttp now supports [GraalVM].</strong></p> <p>Here’s what has changed since 5.0.0-alpha.17:</p> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
35cd96b481 |
fix(phoenix-channel): fail connection in invalid peer cert (#9946)
When being presented an invalid peer certificate, there is no reason why we should retry the connection, it is unlikely to fix itself. Plus, the certificate may get / be cached and a restart of the application is necessary. Resolves: #9944 |
||
|
|
47b35d6e3c |
ci: increase timeout for download roaming test (#9945)
Now that we don't tolerate any failures in the download, this test sometimes fails because the timeout is a bit too tight. |
||
|
|
2038a1bc22 |
chore(ci): Use GitHub Actions Cache for CI layer cache (#9941)
Since GCP artifact registry is cost-prohibitive, we can use the GitHub Actions Cache for docker layer caching for CI builds. See https://docs.docker.com/build/cache/backends/gha/ --------- Signed-off-by: Jamil <jamilbk@users.noreply.github.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> |
||
|
|
b5af132ae8 |
feat(portal): allow queue_target and queue_interval via ENV (#9943)
These parameters should be tuned to how long we expect "normal" queries to take against the SQL instance. For smaller instances, "normal" queries may take longer than 500ms, so we need to be able to configure these via our Terraform configuration. If not specified, the same defaults are used as before. Related: https://github.com/firezone/infra/pull/82 |
||
|
|
5711807a3c |
build(deps): bump open_api_spex from 3.21.2 to 3.21.5 in /elixir (#9927)
Bumps [open_api_spex](https://github.com/open-api-spex/open_api_spex) from 3.21.2 to 3.21.5. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/open-api-spex/open_api_spex/releases">open_api_spex's releases</a>.</em></p> <blockquote> <h2>v3.21.5</h2> <h2>What's Changed</h2> <ul> <li>Fix assert_operation_response/2 references by <a href="https://github.com/zorbash"><code>@zorbash</code></a> in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/673">open-api-spex/open_api_spex#673</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/open-api-spex/open_api_spex/compare/v3.21.4...v3.21.5">https://github.com/open-api-spex/open_api_spex/compare/v3.21.4...v3.21.5</a></p> <h2>v3.21.4</h2> <h2>What's Changed</h2> <ul> <li>Fix OTP-28 support by <a href="https://github.com/bopm"><code>@bopm</code></a> in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/672">open-api-spex/open_api_spex#672</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/bopm"><code>@bopm</code></a> made their first contribution in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/672">open-api-spex/open_api_spex#672</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/open-api-spex/open_api_spex/compare/v3.21.3...v3.21.4">https://github.com/open-api-spex/open_api_spex/compare/v3.21.3...v3.21.4</a></p> <h2>v3.21.3</h2> <h2>What's Changed</h2> <ul> <li>Fix cast x-validate when decoded schema by <a href="https://github.com/GPrimola"><code>@GPrimola</code></a> in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/647">open-api-spex/open_api_spex#647</a></li> <li>Bump CI dependencies by <a href="https://github.com/zorbash"><code>@zorbash</code></a> in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/655">open-api-spex/open_api_spex#655</a></li> <li>Add examples property to Schema by <a href="https://github.com/madjar"><code>@madjar</code></a> in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/654">open-api-spex/open_api_spex#654</a></li> <li>Document schema resolver duplicate titles behaviour by <a href="https://github.com/zorbash"><code>@zorbash</code></a> in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/656">open-api-spex/open_api_spex#656</a></li> <li>Add spec.yaml tasks to example applications by <a href="https://github.com/zorbash"><code>@zorbash</code></a> in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/657">open-api-spex/open_api_spex#657</a></li> <li>Fix 1.18 compilation warnings by <a href="https://github.com/zorbash"><code>@zorbash</code></a> in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/665">open-api-spex/open_api_spex#665</a></li> <li>Check for ex_doc warnings in CI and bump devtest deps by <a href="https://github.com/zorbash"><code>@zorbash</code></a> in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/666">open-api-spex/open_api_spex#666</a></li> <li>Test array query params in example phoenix app by <a href="https://github.com/zorbash"><code>@zorbash</code></a> in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/667">open-api-spex/open_api_spex#667</a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/GPrimola"><code>@GPrimola</code></a> made their first contribution in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/647">open-api-spex/open_api_spex#647</a></li> <li><a href="https://github.com/madjar"><code>@madjar</code></a> made their first contribution in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/654">open-api-spex/open_api_spex#654</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/open-api-spex/open_api_spex/compare/v3.21.2...v3.21.3">https://github.com/open-api-spex/open_api_spex/compare/v3.21.2...v3.21.3</a></p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/open-api-spex/open_api_spex/blob/master/CHANGELOG.md">open_api_spex's changelog</a>.</em></p> <blockquote> <h2>v3.21.5 - 2025-07-08</h2> <ul> <li>Fix assert_operation_response/2 references by <a href="https://github.com/zorbash"><code>@zorbash</code></a> in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/673">open-api-spex/open_api_spex#673</a></li> </ul> <h2>v3.21.4 - 2025-07-01</h2> <ul> <li>Fix OTP-28 support by <a href="https://github.com/bopm"><code>@bopm</code></a> in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/672">open-api-spex/open_api_spex#672</a></li> </ul> <h2>v3.21.3 - 2025-06-25</h2> <ul> <li>Fix cast x-validate when decoded schema by <a href="https://github.com/GPrimola"><code>@GPrimola</code></a> in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/647">open-api-spex/open_api_spex#647</a></li> <li>Add examples property to Schema by <a href="https://github.com/madjar"><code>@madjar</code></a> in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/654">open-api-spex/open_api_spex#654</a></li> <li>Document schema resolver duplicate titles behaviour by <a href="https://github.com/zorbash"><code>@zorbash</code></a> in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/656">open-api-spex/open_api_spex#656</a></li> <li>Fix 1.18 compilation warnings by <a href="https://github.com/zorbash"><code>@zorbash</code></a> in <a href="https://redirect.github.com/open-api-spex/open_api_spex/pull/665">open-api-spex/open_api_spex#665</a></li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
|
79acfd698f |
fix(ci): remove copy binaries step (#9940)
A leftover from #9913 - we need to remove the copy binaries step. |
||
|
|
a8f93d24a3 |
chore(infra): ditch gcp registry for ghcr.io (#9913)
Google Cloud Artifact registry and Cloud storage is a significant cost. GitHub, on the other hand, is completely free due to our being a public repository. Hence, it makes sense to ditch GCP for GHCR. To do this, we move all "staging" artifacts to GHCR. These will then be used in the infra repo to push to GCP for deploys - we probably still want pulls for our infra to hit GCP and not GitHub. One big element of this is that we potentially lose sccache, so I'll be checking the compile time of this PR and looking for alternatives that don't involve such a massive cloud bill. |
||
|
|
318ce24403 |
fix(connlib): resend AssignedIps on traffic for DNS resource (#9904)
This was exposed by #9846. It is being added here as a dedicated PR because the compatibility tests would fail or at least be flaky for the latest client release so we cannot add the integration test right away. |