PubSub subscribers lose sandbox access in LiveView handle_info

[pinetops]

Problem

LiveView processes that subscribe to PubSub topics receive messages in handle_info. When the message handler queries the DB (e.g. Ash.get!), it fails with "record not found" because the LiveView process doesn't have the test's Ecto sandbox access.

The LiveView process IS in the test's $callers chain (sandbox propagated during mount via the sandbox plug). But when a PubSub message arrives from a different process (e.g. Oban worker, another test's LiveView), the handle_info runs in the LiveView's process context — which still has sandbox access from mount.

The issue is that the DB record was created in the test's sandbox transaction, but by the time handle_info fires, the LiveView might be trying to access it through a different connection or the sandbox transaction may have been rolled back.

Reproduction

# test setup creates district in sandbox
district = Test.Factories.District.create(%{name: "Test"})

# LiveView mounts, subscribes to "sync:created" PubSub topic
{:ok, view, _html} = live(conn, "/portal/sync/districts")

# Test triggers a sync which broadcasts PubSub message
# LiveView handle_info receives it and calls:
#   Ash.get!(Rosters.District, resource_id)
# This fails: "record not found" because the district
# was created in the test's sandbox transaction

Workaround

async: false — shared sandbox mode gives all processes access to the same data.

Environment

• sandbox_case 0.3.7
• Phoenix LiveView 1.1.27
• Ecto SQL 3.13.5

[pinetops]

Analysis

$callers is set once during LiveView mount (via the sandbox Hook) and persists for the process lifetime. So handle_info should still have sandbox access — the Ecto adapter checks the executing process's $callers, not who sent the message.

A few things that could cause "record not found" despite having sandbox access:

1. Timing: sandbox rolled back before handle_info fires

The checkin flow is: cleanup callbacks → await_orphans → rollback Ecto → kill_orphans. If the test finishes and rolls back the sandbox before the PubSub message arrives in the LiveView, the district no longer exists.

Question: Is the test still actively running when the handle_info fires? Or does the test assertion complete before the PubSub message arrives?

2. The sync process writes outside the sandbox

If the "sync" that broadcasts the PubSub message runs in a separate process (e.g., Oban worker) that doesn't have sandbox access, its DB operations go through a real connection. The resource_id in the broadcast might refer to a record that doesn't exist in the test's sandbox.

Question: Does the sync process have $callers access? Is it spawned by the test or by something external?

3. Ash uses a different connection/repo

Some Ash resources might be configured with a separate read replica or a different Ecto repo that isn't sandboxed.

Question: Is Ash.get!/2 going through the same repo that sandbox_case checks out?

---

If it's timing (scenario 1), the fix would be to ensure the test waits for the PubSub message to be processed before the test ends. Something like:

# After triggering sync, wait for the LiveView to process the message
assert_has(view, "#district-#{district.id}")

If it's scenario 2, the sync process needs sandbox access — either via $callers propagation or by running the sync inline in the test process.

Could you add some debug logging to confirm which scenario applies?

[pinetops]

Most likely scenario 1 (timing). The test triggers a sync via click, then makes assertions on the page. But the PubSub broadcast from the sync arrives asynchronously — the test may finish and the sandbox rolls back before handle_info processes the message.

With async: false (shared mode), this works because the sandbox stays open until the test process exits. With async: true, the sandbox rolls back immediately after the test's on_exit.

The fix is in the test — it needs to wait for the LiveView to process the PubSub message before completing. For example, asserting on a DOM change that results from the handle_info.

Closing as not-a-bug — the sandbox is working correctly. The test needs to synchronize with the async PubSub delivery.