sanity-io/client

[@sanity/client] running a script with Bun gets the process hanged.

raulfdm opened this issue · 7 comments

raulfdm commented

If you find a security vulnerability, do NOT open an issue. Email security@sanity.io instead.

Describe the bug

Running a simple script using the @sanity/client with bun gets the process hanging forever. This doesn't work with tsx.

To Reproduce

Steps to reproduce the behavior:

  1. Access this repository https://github.com/devraul/bun-sanity-process-hang
  2. Clone it
  3. Follow the README instructions
  4. See error

Expected behavior

Works with bun without problems

Screenshots

CleanShot.2024-04-10.at.07.03.28.mp4

Which versions of Sanity are you using?

Run sanity versions in the terminal and copy-paste the result here.

What operating system are you using?

"@sanity/client": "6.15.11"

Which versions of Node.js / npm are you running?

❯ bun --revision  
1.1.3+2615dc742

Additional context

Since this is an integration problem, I opened the same problem in Bun. Maybe they need to fix something in their side:
oven-sh/bun#10138

bjoerge commented

Interesting. I got it working in an earlier version of bun (v1.0.17 to be specific), but seeing the same behavior as you when switching to bun v1.1.3)

raulfdm commented

Interesting take @bjoerge . I tested each version and it stopped working on v1.1.0. I'll add this comment there

  • 👀1
bjoerge commented

Looks like it could be related to this: oven-sh/bun#7260

stipsan commented

Hi, we tried adding bun conditions in https://github.com/sanity-io/client/releases/tag/v6.15.12 that redirected bun to use the node version of get-it, which uses node:http and node:https under the hood as transport instead of global.fetch.

It created different problems:

image

Surprisingly, changing the bun import conditions to point to the transport that uses fetch appears to solve it:

It's surprising because the assumption has been that bun has used the worker condition until now and always used fetch under the hood.

Here's the basic e2e test we're using:
https://github.com/sanity-io/client/blob/main/runtimes/bun/client.fetch.test.js

The CI tests on Bun 1.1.3, and I've also run the same test locally with Bun 1.1.3 and it works there too.

Give https://github.com/sanity-io/client/releases/tag/v6.15.13 and tell us if that works for you 🙌

  • ❤️1
stipsan commented

Checking the test rig, it started happening last week:
https://github.com/sanity-io/client-runtimes-compatibility/actions/runs/8516205488/job/23324913908

  • @sanity/client@6.15.7
  • bun@1.1.0

Last passing test: https://github.com/sanity-io/client-runtimes-compatibility/actions/runs/8502608803/job/23287010458

  • @sanity/client@6.15.7
  • 1.0.36

Based on this, and the error on the CLI that started happening with Bun 1.1.0 seems to be it started using the node version of get-it and @sanity/client indeed.

Here's how you can check what transport is in use:

import {unstable__adapter, unstable__environment} from '@sanity/client'
import {adapter, environment} from 'get-it'

console.log({unstable__adapter, unstable__environment, adapter, environment})

In bun prior to 1.1.0 adapter reports fetch, afterwards it started using node 🤔

In any case that shouldn't be a problem anymore as we now tell Bun exactly what version to use ☺️

bjoerge commented

Closing as it should be fixed as of @sanity/client@6.15.13

raulfdm commented

Really nice. Thank you for fixing this 🙌