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

Type error with Remix+Vite and Express Server #9500

Closed
3 tasks done
stephen776 opened this issue Nov 9, 2023 · 8 comments · Fixed by getsentry/sentry-wizard#504 or getsentry/sentry-docs#8576
Closed
3 tasks done
Assignees
Labels
Package: remix Issues related to the Sentry Remix SDK Type: Bug

Comments

@stephen776
Copy link

Is there an existing issue for this?

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/remix

SDK Version

7.79.0

Framework Version

No response

Link to Sentry event

No response

SDK Setup

No response

Steps to Reproduce

  • Setup Remix app with new vite config using express server
  • Wire up express request handler using Sentry.wrapExpressRequestHandler

Expected Result

Should run without error

Actual Result

image

@getsantry getsantry bot moved this to Waiting for: Product Owner in GitHub Issues with 👀 Nov 9, 2023
@github-actions github-actions bot added the Package: remix Issues related to the Sentry Remix SDK label Nov 9, 2023
@na2hiro
Copy link

na2hiro commented Nov 10, 2023

This is caused by the extended type for build field passed to createRequestHandler. It can now take a function which returns config object. remix-run/remix@9d516dd#diff-394afa15a85ef1282cf5f441ffbbf61c0a014a7bc9a4790be91ba004f1a21fb3R40

There's a workaround: await the vite server build. This might result in slower startup for dev, but there's no affect for Prod environment.

  wrapExpressCreateRequestHandler(createRequestHandler)({
    build: vite
-      ? () => unstable_loadViteServerBuild(vite)
+      ? await unstable_loadViteServerBuild(vite)
      : await import(BUILD_DIR + "/index.js"),
    ...
  })

Or you might even want to completely omit wrapExpressCreateRequestHandler for dev because you wouldn't use Sentry for reporting errors during development

const createHandler = vite
  ? createRequestHandler
  : wrapExpressCreateRequestHandler(createRequestHandler);
const handlerBuild = vite
  ? () => unstable_loadViteServerBuild(vite)
  : await import(BUILD_DIR + "/index.js");
app.all(
  "*",
  createHandler({
    build: handlerBuild,
    ...
  })
);

@stephen776
Copy link
Author

Thanks for the response.. I tried the second option of just not wrapping the handler in dev, but I am actually getting the exact same error in this scenario as well.

@Lms24
Copy link
Member

Lms24 commented Nov 10, 2023

Hi, thanks for reporting! We'll look into this soon.

@onurtemizkan please take a look at this after Hapi, thanks!

@onurtemizkan
Copy link
Collaborator

I just looked at our implementation, and it seems the most performance-efficient way to solve this is to await and extract the build before providing it to Sentry instrumentation. The whole async logic in this instrumentation is per-request, so there is currently no way to handle this without an API change or breaking performance.

I'm +1 to the first workaround that @na2hiro mentioned:

There's a workaround: await the vite server build. This might result in slower startup for dev, but there's no affect for Prod environment.

 wrapExpressCreateRequestHandler(createRequestHandler)({
    build: vite
-      ? () => unstable_loadViteServerBuild(vite)
+      ? await unstable_loadViteServerBuild(vite)
      : await import(BUILD_DIR + "/index.js"),
    ...
  })

We can mention it in the docs and also can automate this as a part of the wizard. Maybe a part of getsentry/sentry-wizard#495.

@Lms24 what do you think?

@Lms24
Copy link
Member

Lms24 commented Nov 15, 2023

Yes +1 on the first workaround, sounds good to me. RE wizard, yes but let's tackle it in a follow-up PR

@saasc3l
Copy link

saasc3l commented Jan 25, 2024

This is caused by the extended type for build field passed to createRequestHandler. It can now take a function which returns config object. remix-run/remix@9d516dd#diff-394afa15a85ef1282cf5f441ffbbf61c0a014a7bc9a4790be91ba004f1a21fb3R40

There's a workaround: await the vite server build. This might result in slower startup for dev, but there's no affect for Prod environment.

  wrapExpressCreateRequestHandler(createRequestHandler)({
    build: vite
-      ? () => unstable_loadViteServerBuild(vite)
+      ? await unstable_loadViteServerBuild(vite)
      : await import(BUILD_DIR + "/index.js"),
    ...
  })

Or you might even want to completely omit wrapExpressCreateRequestHandler for dev because you wouldn't use Sentry for reporting errors during development

const createHandler = vite
  ? createRequestHandler
  : wrapExpressCreateRequestHandler(createRequestHandler);
const handlerBuild = vite
  ? () => unstable_loadViteServerBuild(vite)
  : await import(BUILD_DIR + "/index.js");
app.all(
  "*",
  createHandler({
    build: handlerBuild,
    ...
  })
);

This now breaks Remix v2.5.x HDR.

@Lms24
Copy link
Member

Lms24 commented Jan 26, 2024

Hey @appist-engineering would you mind creating a new issue with a couple more details please? Thank you!

@haines
Copy link

haines commented Feb 19, 2024

@Lms24 I've created a new issue following up on @appi5t's comment: #10724

AbhiPrasad pushed a commit that referenced this issue Feb 26, 2024
…10784)

Resolves #10724 
Related: #9500

Adds dev-mode support to Remix setups with Vite and Express.

We currently accept Remix server `build` as an object to instrument. But
Remix allows `build` as a synchronous or asynchronous function that
returns the build object. Currently, it seems that functions are only
used in development servers, and not in production. So, while this
update slightly reduces `requestHandler` performance on dev servers, it
does not on production builds.

We need `build` in 2 places:

1- We instrument the loaders / actions on build, then we pass them down
to the original implementations.
2- We use the `routes` inside them to create parameterised transactions.

This update adds new internal wrappers around them to make sure that we
don't miss out on the returned / resolved values in case `build` is a
function, for both cases.

This PR also adds a new E2E test application using the latest Remix
version and Vite, and it runs the tests on `dev` mode.

We also need a documentation update to reflect this, if it gets merged.
onurtemizkan added a commit that referenced this issue Feb 26, 2024
…10784)

Resolves #10724
Related: #9500

Adds dev-mode support to Remix setups with Vite and Express.

We currently accept Remix server `build` as an object to instrument. But
Remix allows `build` as a synchronous or asynchronous function that
returns the build object. Currently, it seems that functions are only
used in development servers, and not in production. So, while this
update slightly reduces `requestHandler` performance on dev servers, it
does not on production builds.

We need `build` in 2 places:

1- We instrument the loaders / actions on build, then we pass them down
to the original implementations.
2- We use the `routes` inside them to create parameterised transactions.

This update adds new internal wrappers around them to make sure that we
don't miss out on the returned / resolved values in case `build` is a
function, for both cases.

This PR also adds a new E2E test application using the latest Remix
version and Vite, and it runs the tests on `dev` mode.

We also need a documentation update to reflect this, if it gets merged.
onurtemizkan added a commit that referenced this issue Feb 26, 2024
…10784)

Resolves #10724
Related: #9500

Adds dev-mode support to Remix setups with Vite and Express.

We currently accept Remix server `build` as an object to instrument. But
Remix allows `build` as a synchronous or asynchronous function that
returns the build object. Currently, it seems that functions are only
used in development servers, and not in production. So, while this
update slightly reduces `requestHandler` performance on dev servers, it
does not on production builds.

We need `build` in 2 places:

1- We instrument the loaders / actions on build, then we pass them down
to the original implementations.
2- We use the `routes` inside them to create parameterised transactions.

This update adds new internal wrappers around them to make sure that we
don't miss out on the returned / resolved values in case `build` is a
function, for both cases.

This PR also adds a new E2E test application using the latest Remix
version and Vite, and it runs the tests on `dev` mode.

We also need a documentation update to reflect this, if it gets merged.
onurtemizkan added a commit that referenced this issue Feb 28, 2024
…10784)

Resolves #10724
Related: #9500

Adds dev-mode support to Remix setups with Vite and Express.

We currently accept Remix server `build` as an object to instrument. But
Remix allows `build` as a synchronous or asynchronous function that
returns the build object. Currently, it seems that functions are only
used in development servers, and not in production. So, while this
update slightly reduces `requestHandler` performance on dev servers, it
does not on production builds.

We need `build` in 2 places:

1- We instrument the loaders / actions on build, then we pass them down
to the original implementations.
2- We use the `routes` inside them to create parameterised transactions.

This update adds new internal wrappers around them to make sure that we
don't miss out on the returned / resolved values in case `build` is a
function, for both cases.

This PR also adds a new E2E test application using the latest Remix
version and Vite, and it runs the tests on `dev` mode.

We also need a documentation update to reflect this, if it gets merged.
onurtemizkan added a commit that referenced this issue Mar 7, 2024
…10784)

Resolves #10724
Related: #9500

Adds dev-mode support to Remix setups with Vite and Express.

We currently accept Remix server `build` as an object to instrument. But
Remix allows `build` as a synchronous or asynchronous function that
returns the build object. Currently, it seems that functions are only
used in development servers, and not in production. So, while this
update slightly reduces `requestHandler` performance on dev servers, it
does not on production builds.

We need `build` in 2 places:

1- We instrument the loaders / actions on build, then we pass them down
to the original implementations.
2- We use the `routes` inside them to create parameterised transactions.

This update adds new internal wrappers around them to make sure that we
don't miss out on the returned / resolved values in case `build` is a
function, for both cases.

This PR also adds a new E2E test application using the latest Remix
version and Vite, and it runs the tests on `dev` mode.

We also need a documentation update to reflect this, if it gets merged.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Package: remix Issues related to the Sentry Remix SDK Type: Bug
Projects
Archived in project
6 participants