Storage upload hangs in later Bun test after previous RLS-denied upload (self-hosted)

[nutzach]

Storage upload hangs in later Bun test after previous RLS-denied upload (self-hosted Supabase)

Environment

• Self-hosted Supabase (supabase/studio:2026.06.03-sha-0bca601)
• Bun 1.3.14 test runner
• Supabase JS client 2.108.2
• File storage with rustFS as a backend
• macOS Tahoe 26.4.1 (Arm64)

Full test file

import { it, expect, describe, afterEach, beforeEach } from "bun:test";
import { createSupabaseClient } from './setup'


describe('Storage tests', () => {
  let supabase: ReturnType<typeof createSupabaseClient>;

  beforeEach(() => {
    supabase = createSupabaseClient();
  });

  afterEach(async () => {
    await supabase.auth.signOut()
  })

  const user = {
    email: 'u1@u1.com',
    password: 'password',
  }
  
  const user2 = {
    email: 'u2@u2.com',
    password: 'password',
  }

  it('should upload an image to storage and be able to retrieve it', async () => {
    // Sign in the test user
    const { data: signInData, error: signInError } = await supabase.auth.signInWithPassword(user)
    if (signInError) {
      throw new Error(`Failed to sign in test user: ${signInError.message}`)
    }
    expect(signInData.session).not.toBeNull()
    const userId = signInData.user.id

    // Read the image file
    const imagePath = 'tests/test_img.jpg'
    const imageFile = Bun.file(imagePath)
    const imageContent = Buffer.from(await imageFile.arrayBuffer())
    const imageName = `test-image-${Date.now()}.jpg`


    // Upload the image to the 'user_profiles' bucket
    const { data: uploadData, error: uploadError } = await supabase.storage
      .from('user_profiles')
      .upload(`${userId}/${imageName}`, imageContent)

    expect(uploadError).toBeNull()
    expect(uploadData).not.toBeNull()

    // Verify the image exists in the bucket
    const { data: listData, error: listError } = await supabase.storage.from('user_profiles').list(userId)

    expect(listError).toBeNull()
    expect(listData).not.toBeNull()
    if (listData) {
      expect(listData.some((file) => file.name === imageName)).toBe(true)
    }

    // Clean up the uploaded image
    const { error: removeError } = await supabase.storage.from('user_profiles').remove([`${userId}/${imageName}`])
    expect(removeError).toBeNull()
  })
  
  it('should not allow uploading to another user\'s folder', async () => {
    // Sign in the test user
    const { error: signInError } = await supabase.auth.signInWithPassword(user)
    expect(signInError).toBeNull()

    // Read the image file
    const imagePath = 'tests/test_img.jpg'
    const imageFile = Bun.file(imagePath)
    const imageContent = Buffer.from(await imageFile.arrayBuffer())
    const imageName = `test-image-${Date.now()}.jpg`

    // Attempt to upload to a different user's folder (e.g. u2's folder or dummy uuid)
    const otherUserId = '00000000-0000-0000-0000-000000000002' // Non-existent user ID for testing
    const { data: uploadData, error: uploadError } = await supabase.storage
      .from('user_profiles')
      .upload(`${otherUserId}/${imageName}`, imageContent)

    expect(uploadData).toBeNull()
    expect(uploadError).not.toBeNull()
    expect(uploadError?.message).toContain('row-level security policy')
  })

  it('should not allow deleting another user\'s image', async () => {
    // Sign in as user2
    const { data: signInData2, error: signInError2 } = await supabase.auth.signInWithPassword(user2)
    if (signInError2) {
      throw new Error(`Failed to sign in test user: ${signInError2.message}`)
    }
    expect(signInData2.session).not.toBeNull()
    const user2Id = signInData2.user.id
    if (!user2Id) throw new Error('user2 not found')

    // User2 uploads an image
    const imagePath = 'tests/test_img.jpg'
    const imageFile = Bun.file(imagePath)
    const imageContent = Buffer.from(await imageFile.arrayBuffer())
    const imageName = `test-image-${Date.now()}.jpg`

    const { error: uploadError } = await supabase.storage
      .from('user_profiles')
      .upload(`${user2Id}/${imageName}`, imageContent)
    expect(uploadError).toBeNull()

    // Now sign in as user1
    await supabase.auth.signOut()
    const { error: signInError1 } = await supabase.auth.signInWithPassword(user)
    expect(signInError1).toBeNull()

    // Attempt to delete user2's image
    const { data: removeData, error: removeError } = await supabase.storage
      .from('user_profiles')
      .remove([`${user2Id}/${imageName}`])

    if (removeError) {
      expect(removeError).not.toBeNull()
    } else {
      expect(removeData).toBeDefined()
      expect(Array.isArray(removeData)).toBe(true)
      expect(removeData?.length).toBe(0) // Should be empty since it failed to delete
    }

    // Verify the image still exists
    const { data: listData, error: listError } = await supabase.storage.from('user_profiles').list(user2Id)
    expect(listError).toBeNull()
    expect(listData).not.toBeNull()
    if (listData) {
      expect(listData.some((file) => file.name === imageName)).toBe(true)
    }

    // Clean up as user2
    await supabase.auth.signOut()
    await supabase.auth.signInWithPassword(user2)
    await supabase.storage.from('user_profiles').remove([`${user2Id}/${imageName}`])
  })

  it('should return an error when uploading an image larger than 5MB', async () => {
    // Sign in the test user
    const { data: signInData, error: signInError } = await supabase.auth.signInWithPassword(user)
    if (signInError) {
      throw new Error(`Failed to sign in test user: ${signInError.message}`)
    }
    expect(signInData.session).not.toBeNull()
    const userId = signInData.user.id

    // Read the oversized image file
    const imagePath = 'tests/test_oversized_img.jpg'
    const imageFile = Bun.file(imagePath)
    const imageContent = Buffer.from(await imageFile.arrayBuffer())
    const imageName = `test-oversized-image-${Date.now()}.jpg`

    // Attempt to upload the image
    const { data: uploadData, error: uploadError } = await supabase.storage
      .from('user_profiles')
      .upload(`${userId}/${imageName}`, imageContent)

    expect(uploadData).toBeNull()
    expect(uploadError).not.toBeNull()
    expect(uploadError?.message).toBe('The object exceeded the maximum allowed size')
  })
})

Issue

I have a storage test suite where one test intentionally triggers an RLS violation by attempting to upload into another user's folder.

If that test runs before another storage upload test, the later upload hangs indefinitely.

The hang occurs on (3rd test case):

await supabase.storage
  .from('user_profiles')
  .upload(...)

The promise never resolves and the test eventually times out.

Important observation

The behavior depends on test order.

Current order:

1. upload image to own folder
2. upload image to another user's folder (expected RLS failure)
3. delete another user's image
4. upload oversized image

Result:

• Test 1 passes
• Test 2 passes
• Test 3 starts but hangs on storage.upload()
• Test suite eventually times out

However, if I move test 2 ("should not allow uploading to another user's folder") to the bottom of the file:

1. upload image to own folder
2. delete another user's image
3. upload oversized image
4. upload image to another user's folder (expected RLS failure)

Then all tests pass.

This makes me suspect either:

• Storage state is leaking between tests
• Auth state is leaking between tests
• A failed upload due to RLS leaves the client or storage service in a bad state
• A self-hosted Storage bug

Additional notes

• Tests are executed sequentially.
• The hanging test definitely starts running.
• The hang occurs specifically on:

await supabase.storage
  .from('user_profiles')
  .upload(...)

• Disabling auth session persistence did not resolve the issue.
• Creating a fresh client in beforeEach() did not resolve the issue.
• Reordering the tests changes the behavior as described above.

Has anyone encountered this behavior before, or is there anything specific I should inspect in the Storage/Auth logs to determine whether this is a client-side issue or a self-hosted Storage issue?

I can also provide other informations as needed.

[VectorPeak]

This looks like the previous failed storage request is leaving something open in the Bun runtime/client connection state, rather than RLS itself “blocking” the next test. A policy-denied upload should come back as a normal Storage API error, usually 403/42501-style depending on where it fails, and the next request should still be able to proceed.

The first thing worth isolating is whether the hang is tied to reusing the same SupabaseClient / auth session / HTTP connection after the denied upload. Since this is in Bun, I would make the denied-upload test fully self-contained and force a fresh client for the next test:

afterEach(async () => {
 await supabase.auth.signOut()

 // Give Bun a chance to close pending fetch/body work between tests.
 await new Promise((resolve) => setTimeout(resolve, 0))
})

Also make sure the denied upload is not accidentally leaving a promise unobserved. The denied request should be awaited and asserted directly:

const { data, error } = await supabase.storage
 .from('user_profiles')
 .upload(`${otherUserId}/${imageName}`, imageContent)

expect(data).toBeNull()
expect(error).not.toBeNull()

If the next upload still hangs, try creating a completely new Supabase client after the denied upload rather than only signing out:

afterEach(async () => {
 await supabase.auth.signOut()
 supabase = undefined as any
})

And in each test:

beforeEach(() => {
 supabase = createSupabaseClient()
})

One important thing in this test setup: avoid sharing the same storage object path across tests. If two tests generate Date.now() names close together, or if a failed test leaves an object behind, later uploads can behave differently depending on upsert, ownership policies, and object metadata. I’d include the test name/user id plus a random suffix:

const imageName = `test-image-${crypto.randomUUID()}.jpg`

For the RLS test specifically, I would also verify that the policy is denying at the storage.objects layer and not timing out while talking to rustFS. A quick way to separate those is to check the Storage service logs while the test hangs. If the denied request logs a completed 403 but the following upload never reaches storage-api, that points more toward Bun/client connection reuse. If the following upload reaches storage-api and stalls while writing to rustFS, that points at the storage backend path instead.

A useful workaround to confirm the connection-reuse theory is to inject a fetch implementation that does not reuse state between requests, or at least add a timeout wrapper around the storage call so the test fails with context instead of hanging forever:

async function withTimeout<T>(promise: Promise<T>, ms = 10_000): Promise<T> {
 const timeout = new Promise<never>((_, reject) =>
 setTimeout(() => reject(new Error(`Timed out after ${ms}ms`)), ms)
 )

 return Promise.race([promise, timeout])
}

const { data, error } = await withTimeout(
 supabase.storage
 .from('user_profiles')
 .upload(`${userId}/${imageName}`, imageContent),
)

The snippet is cut off at signI, so the exact denied upload path and the later hanging test are missing. The most useful extra details would be:

• the rest of the denied-upload test and the test that hangs;
• the exact RLS policies on storage.objects;
• whether the hang happens with Node/Vitest or only with bun:test;
• storage-api logs for the denied request and the subsequent hanging upload;
• whether the same behavior occurs with the default S3/minio-compatible backend instead of rustFS.

---

If my answer solved your problem, you can click answered the question. I'm really here to help, and along the way I'm also collecting Galaxy Brain badges haha 😆

[harrysun2006]

The "a previous RLS-denied upload makes a later upload hang" pattern almost always points at the HTTP transport rather than Storage itself — specifically an error response whose body never gets drained, leaving a keep-alive socket in a bad state that the next request then blocks on. Bun's fetch has had a few sharp edges here.

When the RLS check denies the upload, storage-js gets a non-2xx response. If that error body isn't fully consumed, the underlying connection can be reused in a half-read state, and the next upload on that connection just sits there. A signed-out client in afterEach doesn't help because the transport/agent is process-global, not per-client.

Things worth trying, roughly in order:

1. Rule out Bun first: run the same test file under Node + vitest (or node:test). If it passes there, you've confirmed it's Bun's fetch, and the discussion moves to a Bun issue rather than Supabase.
2. Force connections closed in the test env so a poisoned socket can't be reused — e.g. send Connection: close, or disable keep-alive for the test run.
3. Drain the error response: after the denied upload, make sure the error path actually reads the body (storage-js should, but if you're catching early, the body may be left dangling).
4. Add a hard timeout to the hanging upload so a stuck socket fails fast instead of hanging the whole suite, which also makes the repro clearer.

If it turns out to reproduce under Node too, then it's more likely the self-hosted Storage API (or rustFS) holding a lock on the object key after the denied attempt — in that case the storage container logs around the denied request vs. the hung one would be the next thing to compare. Do you see it under Node/vitest, or only Bun?