feat(dashboard-api): populate Ory identity external_id on admin bootstrap

[ben-fornefeld]

What

During OIDC admin user bootstrap, set the Ory identity's external_id to the canonical public.users.id UUID after the user row has been committed.

Details

• Added SetIdentityExternalID(ctx, subject, externalID) to the userprofile.Provider interface.
• Implemented it on oryProvider via Ory PatchIdentity (JSON patch replace /external_id).
• bootstrapUserWithIdentity calls the setter after each commit (existing-team and new-team paths), only for OIDC bootstrap (identity present). If the Ory update fails, bootstrap hard-fails and returns the error.

[cursor]

PR Summary

Medium Risk
Ory is updated before the database transaction commits, so a successful patch followed by a rollback or commit failure can leave external_id set in Ory without a matching committed user row. Bootstrap failure on Ory errors also makes signup depend on Ory admin API availability.

Overview
During OIDC admin user bootstrap, the API sets each Ory identity’s external_id to the canonical public.users.id once the user and identity rows exist in the open bootstrap transaction. A new SetIdentityExternalID on userprofile.Provider is implemented for Ory with a JSON Patch add on /external_id so first-time and repeat bootstraps stay idempotent. Bootstrap calls this step only when an OIDC identity is present and fails the whole bootstrap if Ory rejects the patch; handler and Ory provider tests cover the wiring and patch shape.

^{Reviewed by Cursor Bugbot for commit 0bc61ea. Bugbot is set up for automated code reviews on this repo. Configure here.}

[gemini-code-assist]

Code Review

Calling setOIDCIdentityExternalID after committing the transaction but before provisioning the team can block team provisioning permanently if the Ory update fails, as subsequent retries will skip provisioning due to the team's age. Additionally, returning an error when setOIDCIdentityExternalID fails for an existing user unnecessarily blocks the bootstrap process and prevents login, even though the user and team are already successfully committed. Logging these errors instead of returning them ensures the critical path of team provisioning and user login is not blocked.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[codecov]

❌ 4 Tests Failed:

Tests completed	Failed	Passed	Skipped
2980	4	2976	6

View the top 3 failed test(s) by shortest run time

github.com/e2b-dev/infra/tests/integration/internal/tests/api/templates::TestTemplateBuildRUN

Stack Traces | 0s run time

=== RUN   TestTemplateBuildRUN
=== PAUSE TestTemplateBuildRUN
=== CONT  TestTemplateBuildRUN
--- FAIL: TestTemplateBuildRUN (0.00s)

github.com/e2b-dev/infra/tests/integration/internal/tests/api/templates::TestTemplateBuildRUN/Single_RUN_command

Stack Traces | 166s run time

=== RUN   TestTemplateBuildRUN/Single_RUN_command
=== PAUSE TestTemplateBuildRUN/Single_RUN_command
=== CONT  TestTemplateBuildRUN/Single_RUN_command
    build_template_test.go:133: test-ubuntu-run: [info] Building template ycgywmapzs8fu35fnw3g/778c622a-d853-4ef4-a03b-c08adc55a042
    build_template_test.go:133: test-ubuntu-run: [info] [base] FROM ubuntu:22.04 [905bb9b1f7b3e631aa9d97d25385b3bb55c45687cb0f33deab700d7906575727]
    build_template_test.go:133: test-ubuntu-run: [info] Base Docker image size: 30 MB
    build_template_test.go:133: test-ubuntu-run: [info] Creating file system and pulling Docker image
    build_template_test.go:133: test-ubuntu-run: [info] Uncompressing layer sha256:40d16f30db405106ef8074779bdf41f012465c2a785bbeaa2eab9f2081099b47 30 MB
    build_template_test.go:133: test-ubuntu-run: [info] Uncompressing layer sha256:fa07423710b93b4cc200e9b5a1edb9026010c9d1c8b0853912047779e227d7f9 13 MB
    build_template_test.go:133: test-ubuntu-run: [info] Uncompressing layer sha256:8c4b1b28875140ed3abacaf16ad0d696f6bef912f52d2148f261a23e3349465b 168 B
    build_template_test.go:133: test-ubuntu-run: [info] Layers extracted
    build_template_test.go:133: test-ubuntu-run: [info] Root filesystem structure: bin, boot, dev, etc, home, lib, lib32, lib64, libx32, media, mnt, opt, proc, root, run, sbin, srv, sys, tmp, usr, var
    build_template_test.go:133: test-ubuntu-run: [info] Provisioning sandbox template
    build_template_test.go:133: test-ubuntu-run: [info] Provisioning was successful, cleaning up
    build_template_test.go:133: test-ubuntu-run: [info] Sandbox template provisioned
    build_template_test.go:133: test-ubuntu-run: [info] [base] DEFAULT USER user [ea1d9e9a4e5e72b3edd251b28ade9fa6aa5a91811560507694d4964fdbac723b]
    build_template_test.go:133: test-ubuntu-run: [info] [builder 1/1] RUN echo 'Hello, World!' [3a7c1b087bdada710574e91a5484a97044150a027127d59c9b2df2bec44bdd33]
    build_template_test.go:133: test-ubuntu-run: [info] [builder 1/1] [stdout]: Hello, World!
    build_template_test.go:133: test-ubuntu-run: [info] [finalize] Finalizing template build [bf952c855fff6cfdd2ac81baf7c186afcaf50eaeee6b2a47b347408b7390e652]
    build_template_test.go:133: test-ubuntu-run: [error] Build failed: build was cancelled
    build_template_test.go:166: Build failed: {<nil> build was cancelled <nil>}
--- FAIL: TestTemplateBuildRUN/Single_RUN_command (166.46s)

github.com/e2b-dev/infra/tests/integration/internal/tests/api/templates::TestTemplateBuildCOPY

Stack Traces | 182s run time

=== RUN   TestTemplateBuildCOPY
=== PAUSE TestTemplateBuildCOPY
=== CONT  TestTemplateBuildCOPY
    build_template_test.go:133: test-ubuntu-copy: [info] Building template ph3z5hm0d06klj6milgj/6d2a6337-5270-4622-8b75-413afe87542a
    build_template_test.go:133: test-ubuntu-copy: [info] [base] FROM ubuntu:24.04 [c39b5437504679a3bf3ba259cd432b64e76eb59a37a904738b53964916ce30d5]
    build_template_test.go:133: test-ubuntu-copy: [info] Base Docker image size: 30 MB
    build_template_test.go:133: test-ubuntu-copy: [info] Creating file system and pulling Docker image
    build_template_test.go:133: test-ubuntu-copy: [info] Uncompressing layer sha256:cb259a83ac3dd9fea0b394df41df2b298adf0df938fef5999475af18a751c257 30 MB
    build_template_test.go:133: test-ubuntu-copy: [info] Uncompressing layer sha256:fa07423710b93b4cc200e9b5a1edb9026010c9d1c8b0853912047779e227d7f9 13 MB
    build_template_test.go:133: test-ubuntu-copy: [info] Uncompressing layer sha256:8c4b1b28875140ed3abacaf16ad0d696f6bef912f52d2148f261a23e3349465b 168 B
    build_template_test.go:133: test-ubuntu-copy: [info] Layers extracted
    build_template_test.go:133: test-ubuntu-copy: [info] Root filesystem structure: bin, boot, dev, etc, home, lib, lib64, media, mnt, opt, proc, root, run, sbin, srv, sys, tmp, usr, var
    build_template_test.go:133: test-ubuntu-copy: [info] Provisioning sandbox template
    build_template_test.go:133: test-ubuntu-copy: [info] Provisioning was successful, cleaning up
    build_template_test.go:133: test-ubuntu-copy: [info] Sandbox template provisioned
    build_template_test.go:133: test-ubuntu-copy: [info] [base] DEFAULT USER user [3da537a117dca86581b7ada95bd60bd622d9251689edd72ea31f576d71870989]
    build_template_test.go:133: test-ubuntu-copy: [info] [builder 1/2] COPY . /app/ [b68d7028b17386e4debf2f779f7e9fe80a664e3401f338e37621c8e9a1339c9e]
    build_template_test.go:133: test-ubuntu-copy: [info] [builder 2/2] RUN cat /app/hello.txt | grep 'Hello from COPY!' [42c96f33b688b5977efb52758632c7a749a455bd99d156205eafc5d884f8ffbc]
    build_template_test.go:133: test-ubuntu-copy: [info] [builder 2/2] [stdout]: Hello from COPY!
    build_template_test.go:133: test-ubuntu-copy: [info] [finalize] Finalizing template build [297e24b5987786ae506bda0af96675039461afed1fcd4ec7a1f51572f618eed3]
    build_template_test.go:133: test-ubuntu-copy: [error] Build failed: build was cancelled
    build_template_test.go:1156: Build failed: {<nil> build was cancelled <nil>}
--- FAIL: TestTemplateBuildCOPY (181.99s)

github.com/e2b-dev/infra/tests/integration/internal/tests/envd::TestCommandKillNextApp

Stack Traces | 260s run time

=== RUN   TestCommandKillNextApp
=== PAUSE TestCommandKillNextApp
=== CONT  TestCommandKillNextApp
    process_test.go:30: Build failed: {<nil> build was cancelled <nil>}
--- FAIL: TestCommandKillNextApp (260.14s)

To view more test analytics, go to the Test Analytics Dashboard
_{📋 Got 3 mins? Take this short survey to help us improve Test Analytics.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4ccab566f5

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit be6327f. Configure here.}

[claude]

Additional findings (outside current diff — PR may have been updated during review):

• 🔴 packages/dashboard-api/internal/handlers/utils_team_provisioning.go:230-232 — On the new-team path, setOIDCIdentityExternalID runs between tx.Commit and ProvisionTeam (lines 226-242). If the Ory PATCH fails transiently, the user/identity/team/membership rows are durably committed but billing provisioning is never invoked. Recovery is bounded by the existing-team path's 30s bootstrapProvisionRetryAge window — if Ory is degraded for >30s the team is permanently half-bootstrapped without billing. Suggest swapping the order on the new-team path so ProvisionTeam (already error-ignored via _ =) runs first, preserving the "billing is always attempted at least once" invariant the retry window relies on.

  Extended reasoning...

  The regression. Before this PR the new-team path was: tx.Commit → _ = teamProvisionSink.ProvisionTeam(...) (fire-and-forget). After this PR the order is: tx.Commit → setOIDCIdentityExternalID (hard-fail) → ProvisionTeam. The Ory PATCH was inserted between the commit and the (already error-swallowed) provision call, so any transient PATCH failure short-circuits provisioning entirely.

  Why the 30s retry window doesn't save us. The existing-team path at lines 171-200 was designed to recover silent ProvisionTeam failures: it re-invokes ProvisionTeam, but only when time.Since(existingTeam.CreatedAt) < bootstrapProvisionRetryAge (30 seconds). That window was sized around the implicit invariant that ProvisionTeam was attempted at least once on initial bootstrap. The PR breaks that invariant: now an Ory PATCH failure can prevent the first attempt entirely. Worse, on retry the existing-team path also calls setOIDCIdentityExternalID (line 177) before checking the 30s window — so if Ory's admin API stays degraded, every retry returns early and never even reaches the ProvisionTeam call.

  Plausibility of the trigger. Ory's admin API (where PatchIdentity lives) is operationally separate from the self-service auth APIs that issue tokens. A partial Ory outage, rate-limit blip, or admin-token rotation can leave the admin endpoint unreachable while OIDC auth keeps succeeding — exactly the conditions that fire a bootstrap. greping the repo confirms bootstrapProvisionRetryAge is used nowhere else and there is no async reconciler — ProvisionTeam is only called from synchronous request-path sites in utils_team_provisioning.go, so a missed call is unrecoverable without manual intervention.

  Step-by-step proof.

  1. New user starts OIDC bootstrap. bootstrapUserWithIdentity runs the new-team path.
  2. Line 226: tx.Commit succeeds. public.users, identity, team, and users_teams row are durable.
  3. Line 230: setOIDCIdentityExternalID calls oryProvider.SetIdentityExternalID → ory.PatchIdentity returns a transient error (502 from admin API).
  4. Line 231: function returns provisionedTeam{}, err. The teamProvisionSink.ProvisionTeam call at line 242 is never reached.
  5. The user retries 60s later. The existing-team path runs.
  6. Line 177: setOIDCIdentityExternalID is called again. If Ory recovered, it succeeds; if still degraded, it errors and we loop.
  7. Once setOIDCIdentityExternalID finally succeeds, line 181 checks time.Since(existingTeam.CreatedAt) < 30s. Because the team was created >30s ago, the condition is false and ProvisionTeam is never called.
  8. Result: team and membership exist in our DB, identity has external_id set in Ory, but the billing sink was never invoked. No reconciler will fix this.

  Fix. Swap the two calls on the new-team path so ProvisionTeam runs before setOIDCIdentityExternalID. The operations are independent: ProvisionTeam doesn't need external_id, and the Ory PATCH doesn't need billing state. Since the ProvisionTeam call is already _ = (errors swallowed), this is a one-line reordering that costs nothing and restores the "always attempt billing once per new team" invariant the existing-team retry window depends on. The existing-team path (lines 174-180) has the same shape but is less load-bearing because the path only runs when a team already exists; still, applying the same swap there is consistent.