withastro / astro

The web framework for content-driven websites. ⭐️ Star to support our work!
https://astro.build
Other
46.8k stars 2.49k forks source link

Astro Actions: "Error: Unable to get API context." when is sended arguments to an action. #11423

Closed ynhhoJ closed 3 months ago

ynhhoJ commented 4 months ago

Astro Info

Astro                    v4.11.5
Node                     v18.20.3
System                   Linux (x64)
Package Manager          unknown
Output                   server
Adapter                  @astrojs/node
Integrations             @astrojs/preact

If this issue only occurs in one browser, which browser is a problem?

Firefox

Describe the Bug

I followed example from Actions Proposal and everytime when is called an action with arguments like:

await actions.like({ postId })

Is returned error: Uncaught (in promise) Error: Unable to get API context. and 500 HTTP Status

But if we do:

await actions.like()

We get 400 HTTP Status and validation input error. image

What's the expected result?

There is no error when action:

await actions.like({ postId })

is called

Link to Minimal Reproducible Example

https://stackblitz.com/edit/withastro-astro-pdghi3?file=src%2Fcomponents%2FLike.tsx

Participation

florian-lefebvre commented 4 months ago

Yeah I think the 500 error should not occur here but be a 400 instead. @bholmesdev wdyt?

bholmesdev commented 4 months ago

Thanks for reporting @ynhhoJ! I just confirmed this a Stackblitz issue, but does not occur locally. Is that true for you as well? That 500 error is indeed unexpected

ynhhoJ commented 4 months ago

@bholmesdev , originally, on on my machine:

Astro                    v4.11.5
Node                     v20.15.0
System                   Linux (x64)
Package Manager          bun
Output                   server
Adapter                  @astrojs/node
Integrations             i18n:custom
                         @astrojs/tailwind
                         @astrojs/preact

I got another error Unexpected end of JSON input, every time when action has a body payload. So this is the cause why I opened this issue.

It's very strange:

Image ![image](https://github.com/withastro/astro/assets/22500212/77b73697-a23a-426c-864c-612ed54c5f74)

UPD: This error happens only with bun run --bun dev, if I run project from npm run dev, everything is OK

image

bholmesdev commented 4 months ago

got it. So to clarify @ynhhoJ: do all of the 500 errors you reported go away when using npm? We don't officially support bun, so I'd like to table that dsicussion

ynhhoJ commented 4 months ago

do all of the 500 errors you reported go away when using npm?

Yeah. I opened an issue to bun repo.

Thank you!

ynhhoJ commented 4 months ago

Sorry for issue close, maybe 500 error should be fixed by Astro team :D

But Unexpected end of JSON input will be on Bun side

bholmesdev commented 4 months ago

@ynhhoJ Alright got it, that's good info. I know we rely on the node:async_hooks import for API context. It seems Bun has implemented this, but it could be an issue with the combo of Node and Vite. Not sure which side that issue is on yet.

florian-lefebvre commented 4 months ago

Also stackblitz has issues with ALSs

bholmesdev commented 3 months ago

Using this issue to track errors with edge middleware on Netlify and Vercel. Bun issue has been raised in their repository, and Stackblitz will take cross communication

bholmesdev commented 3 months ago

Alright, we removed async local storage from the Actions implementation, which should help with support in Bun and other environments. That still left your JSON parse error, which I think I've gotten to the bottom of!

We use request.clone().json() to read your input from the Action handler function. For some reason, calling .clone() clears out the response body in Bun (but not other environments). The .clone() is unnecessary and easy to remove on our end. The issue is being tracked in Bun but unfortunately has not seen a fix yet.

bholmesdev commented 3 months ago

@ynhhoJ Well, I'm glad our unit testing suite exists. I've discovered the .clone() is necessary to support reading the ctx.request body directly from an action. I unfortunately needed to close that PR.

I'm hopeful Bun can get this issue resolved on their end! But for now, I suggest removing the --bun flag when using Astro Actions.