Files
firezone/elixir
dependabot[bot] 928bb89822 build(deps): bump oban from 2.19.4 to 2.20.1 in /elixir (#10437)
Bumps [oban](https://github.com/oban-bg/oban) from 2.19.4 to 2.20.1.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/oban-bg/oban/releases">oban's
releases</a>.</em></p>
<blockquote>
<h2>v2.20.0</h2>
<p>This release brings a fantastic new helper function, an optional
migration to aid pruning, some stability improvements, and a bevy of
documentation updates.</p>
<h2>🦋 Update Job</h2>
<p>This introduces the <code>Oban.update_job/2,3</code> function to
simplify updating existing jobs while ensuring data consistency and
safety. Previously, updating jobs required manually constructing change
operations or complex queries that could lead to race conditions or
invalid state changes.</p>
<p>Only a curated subset of job fields, e.g. <code>:args</code>,
<code>:max_attempts</code>, <code>:meta</code>, etc. may be updated and
they use the same validation rules as insertion to prevent invalid data.
Updates are also wrapped in a transaction with locking clauses to
prevent concurrent modifications.</p>
<p>The function supports direct map changes:</p>
<pre lang="elixir"><code>Oban.update_job(job, %{priority: 0, tags:
[&quot;urgent&quot;]})
</code></pre>
<p>It also has a convenient function-based mode for dynamic changes:</p>
<pre lang="elixir"><code>Oban.update_job(job, fn job -&gt; 
  %{meta: Map.put(job.meta, &quot;processed_by&quot;, current_node())} 
end)
</code></pre>
<h2>❄️ Unique State Groups</h2>
<p>There are now named unique state groups to replace custom state lists
for unique jobs, promoting better uniqueness design and reducing
configuration errors.</p>
<p>Previously, developers had to manually specify lists of job states
for uniqueness, which was error-prone and could lead to subtle bugs when
states were omitted or incorrectly combined. The new predefined groups
ensure correctness and consistency across applications.</p>
<p>The new state groups are:</p>
<ul>
<li><strong><code>:all</code></strong> - All job states</li>
<li><strong><code>:incomplete</code></strong> - Jobs that haven't
finished (<code>~w(available scheduled executing
retryable)a</code>)</li>
<li><strong><code>:scheduled</code></strong> - Only scheduled jobs
(<code>[:scheduled]</code>)</li>
<li><strong><code>:successful</code></strong> - Jobs that completed
successfully (<code>~w(available scheduled executing retryable
completed)a</code>)</li>
</ul>
<p>These groups eliminate the risk of accidentally creating incomplete
or incorrect state lists that could allow duplicate jobs to be created
when they shouldn't be, or prevent valid job creation when duplicates
should be allowed.</p>
<h2>🪺 Nested Plugin Supervision</h2>
<p>Plugins and the internal Stager are now nested within a secondary
supervision tree to improve system resilience and stability.</p>
<p>Previously, plugins were supervised directly under the main Oban
supervisor alongside core process. This meant that plugin failures could
potentially impact the entire Oban system, and frequent plugin restarts
could trigger cascading failures in the primary supervision tree.</p>
<p>The new supervisor has more lenient restart limits to allow for more
plugin restart attempts before giving up. This change makes Oban more
robust in production environments where plugins may experience transient
failures due to database or connectivity issues.</p>
<h2>v2.20.0 — 2025-08-13</h2>
<h3>Enhancements</h3>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/oban-bg/oban/blob/main/CHANGELOG.md">oban's
changelog</a>.</em></p>
<blockquote>
<h2>v2.20.1 — 2025-08-15</h2>
<h3>Bug Fixes</h3>
<ul>
<li>
<p>[Worker] Handle missing fields in unique Worker validation.</p>
<p>Workers that specified <code>keys</code> without <code>fields</code>
would fail validation at compile time. Now
default values are considered for <code>use Oban.Worker</code> as well
as <code>Job.new/2</code>.</p>
</li>
</ul>
<h2>v2.20.0 — 2025-08-13</h2>
<h3>Enhancements</h3>
<ul>
<li>
<p><code>Migration</code> Add V13 migration for indexing cancelled and
discarded states.</p>
<p>A new V13 migration adds compound indexes to significantly improve
<code>Oban.Plugins.Pruner</code>
performance when cleaning up <code>discarded</code> and
<code>cancelled</code> jobs. This is especially beneficial for
applications that process large volumes of jobs and retain them for
extended periods.</p>
</li>
<li>
<p><code>Repo</code> Expose dynamic repo switching as
<code>with_dynamic_repo/2</code></p>
<p>The function was previously internal, which made impossible to use in
external modules or extend
upon. Now custom plugins and extensions can use
<code>Repo.with_dynamic_repo/2</code> to use the configured
dynamic repo options.</p>
</li>
</ul>
<h3>Bug Fixes</h3>
<ul>
<li>
<p>[Oban] Allow <code>insert_all/1,3</code> via Oban facade</p>
<p>The <code>insert_all/1</code> and <code>insert_all/3</code> function
variants were missing from the generated Oban
facade functions when using a named instance.</p>
</li>
<li>
<p>[Testing] Generate correct <code>perform_job/1,2,3</code>
clauses.</p>
<p>The <code>perform_job/2,3</code> clauses generated by <code>use
Oban.Testing</code> didn't handle the <code>perform_job/2</code>
variant designed to run jobs created with <code>build_job/3</code>. This
caused test failures when trying
to execute jobs built using the <code>build_job/3</code> helper
function.</p>
<p>The fix generates the missing <code>perform_job/2</code> clause along
with a convenient <code>perform_job/1</code>
variant, ensuring all testing scenarios work seamlessly regardless of
how jobs are constructed.</p>
</li>
<li>
<p>[Testing] Restrict inline execution to <code>available</code> and
<code>scheduled</code> states.</p>
<p>Jobs in the <code>completed</code> state or other non-runnable states
were incorrectly attempted by the
inline engine, potentially causing errors or unexpected behavior during
testing.</p>
</li>
<li>
<p>[Worker] Disallow <code>:keys</code> when <code>:fields</code>
doesn't contain <code>:args</code> or <code>:meta</code></p>
<p>Unique job configurations using <code>:keys</code> were allowed even
when <code>:fields</code> didn't include <code>:args</code>
or <code>:meta</code>, which would result in runtime errors since keys
can only extract values from these</p>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="d177b524ad"><code>d177b52</code></a>
Release v2.20.1</li>
<li><a
href="74756b3269"><code>74756b3</code></a>
Handle missing fields in Worker unique</li>
<li><a
href="65016963a8"><code>6501696</code></a>
Release v2.20.0</li>
<li><a
href="baec2df2ef"><code>baec2df</code></a>
Bump actions/checkout from 4 to 5 (<a
href="https://redirect.github.com/oban-bg/oban/issues/1331">#1331</a>)</li>
<li><a
href="215981e3bb"><code>215981e</code></a>
Restrict inline execution to available/scheduled</li>
<li><a
href="f2c26cc147"><code>f2c26cc</code></a>
Remove commented out dead code from installer</li>
<li><a
href="d07f740f29"><code>d07f740</code></a>
Bump the production-dependencies group with 2 updates (<a
href="https://redirect.github.com/oban-bg/oban/issues/1328">#1328</a>)</li>
<li><a
href="0d462e9d51"><code>0d462e9</code></a>
Fix duplicate word typo (<a
href="https://redirect.github.com/oban-bg/oban/issues/1327">#1327</a>)</li>
<li><a
href="d1124e68df"><code>d1124e6</code></a>
Bump the production-dependencies group with 2 updates (<a
href="https://redirect.github.com/oban-bg/oban/issues/1325">#1325</a>)</li>
<li><a
href="902d8c9b97"><code>902d8c9</code></a>
Nest plugins within a secondary supervision tree</li>
<li>Additional commits viewable in <a
href="https://github.com/oban-bg/oban/compare/v2.19.4...v2.20.1">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=oban&package-manager=hex&previous-version=2.19.4&new-version=2.20.1)](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>
2025-09-23 17:41:29 +00:00
..

Firezone Elixir Development

Before reading this doc, make sure you've read through our CONTRIBUTING guide.

Getting Started

This is not an in depth guide for setting up all dependencies, but it should give you a starting point.

Prerequisites:

  • All prerequisites in the CONTRIBUTING guide
  • Install ASDF and all plugins/tools from .tool-version in the top level of the Firezone repo
  • Install pnpm

From the top level director of the Firezone repo start the Postgres container:

docker compose up -d postgres

Inside the /elixir directory run the following commands:

# Install dependencies
# --------------------
> mix deps.get

# Install npm packages and build assets
# -------------------------------------
> cd apps/web/
> mix setup

# Setup and seed the DB
# ---------------------
> cd ../..
> mix ecto.seed

# Start all of the portal Elixir apps:
# ------------------------------------
> iex -S mix

The web and api applications should now be running:

Stripe integration for local development

Prerequisites:

  • Stripe account
  • Stripe CLI

Steps:

  • Use static seeds to provision account ID that corresponds to staging setup on Stripe:

    STATIC_SEEDS=true mix do ecto.reset, ecto.seed
    
  • Start Stripe CLI webhook proxy:

    stripe listen --forward-to localhost:13001/integrations/stripe/webhooks
    
  • Start the Phoenix server with enabled billing from the elixir/ folder using a test mode token:

    cd elixir/
    BILLING_ENABLED=true STRIPE_SECRET_KEY="...copy from stripe dashboard..." STRIPE_WEBHOOK_SIGNING_SECRET="...copy from stripe cli tool.." mix phx.server
    

When updating the billing plan in stripe, use the Stripe Testing Docs for how to add test payment info

WorkOS integration for local development

Prerequisites:

  • WorkOS account

WorkOS is currently being used for JumpCloud directory sync integration. This allows JumpCloud users to use SCIM on the JumpCloud side, rather than having to give Firezone an admin JumpCloud API token.

Connecting WorkOS in dev mode for manual testing

If you are not planning to use the JumpCloud provider in your local development setup, then no additional setup is needed. However, if you need to use the JumpCloud provider locally, you will need to obtain an API Key and Client ID from the WorkOS Dashboard.

After obtaining WorkOS API credentials, you will need to make sure they are set in the environment ENVs when starting your local dev instance of Firezone. As an example:

WORKOS_API_KEY="..." WORKOS_CLIENT_ID="..." mix phx.server

Acceptance tests

You can disable headless mode for the browser by adding

@tag debug: true
feature ....