Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug?]: <HttpStatusCode> doesn't work in mode:async #1410

Closed
2 tasks done
indeyets opened this issue Mar 22, 2024 · 2 comments
Closed
2 tasks done

[Bug?]: <HttpStatusCode> doesn't work in mode:async #1410

indeyets opened this issue Mar 22, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@indeyets
Copy link
Contributor

Duplicates

  • I have searched the existing issues

Latest version

  • I have tested the latest version

Current behavior 😯

Whenever solid-start's server rendering is in async-mode, <HttpStatusCode does nothing

Expected behavior 🤔

it should be possible to change status of responses using <HttpStatusCode> in async mode

Steps to reproduce 🕹

Steps:

  1. checkout https://github.com/indeyets/solid-start-error and install dependencies
  2. run npm run dev
  3. notice that status is supposed to be be 404: https://github.com/indeyets/solid-start-error/blob/main/src/app.tsx#L23
  4. run curl --HEAD -v 'http://localhost:3000/' (or use browser's developer tools) and see that it still returns 200 OK

Context 🔦

No response

Your environment 🌎

No response

@indeyets indeyets added the bug Something isn't working label Mar 22, 2024
@ryansolid
Copy link
Member

Thanks for reporting. I think we hit this before but forgot to track it. This is likely a Solid core bug but will investigate.

@ryansolid
Copy link
Member

Yeah this is an interesting one. Because I thought the issue was in Solid but it is more that while I can delay cleanup there we still have a problem because we are basing our undo on whether the response has been handled and really it depends on whether its been handled or conceptually we are done rendering. It's possible that we haven't returned the response and it is done rendering in which case we should skip it like this and there are cases where we have responded on the stream and shouldn't clear it even though we aren't done rendering.

Ideally we'd have a generic way to handle this, but for now I think start should mark when it thinks it is done rendering and we check either condition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants