[Bug]: createMemorySessionStorage doesn't actually work in development

[pckilgore]

Which Remix packages are impacted?

• remix (Remix core)
• @remix-run/dev

What version of Remix are you using?

1.1.3

What version of Node are you using? Minimum supported version is 14.

16.13.0

Steps to Reproduce

use createMemorySessionStorage

Expected Behavior

sessions are preserved for the duration of the development session remix dev (or at least, preserved between changes to the underlying source).

Actual Behavior

in-memory session storage wiped after each request, even if no source code has changed.

Elaboration

I expected this API to be usable like:

export default process.env.NODE_ENV === "production"
    ? createCustomDBStore(cookie)
    : createMemorySessionStore(cookie)

Perhaps if this is not the intent and it is only intended for the case of "deployed development" environments, more clearly document that fact.

[pckilgore]

Worked around in development with createFileSessionStorage

[akomm]

When something in the file where you create the storage OR a file it depends on changes, it will be rebuild and reloaded. That might cause the wipe of the instance. I just guess because I only see the export, but it depends on cookie, so there is more, than just the default export, right? Can you check?

[confix]

As of remix-serve

In development, remix-serve will ensure the latest code is run on each request by purging the require cache of your application modules when files change.

this might be what you are seeing.

#1818 implies that purging is happening per request and not when files have actually changed. I did not validate the assumption yet.

[pckilgore]

Purging appears to occur per request. It's reasonable to have the in-memory store refresh if a code change occurs.

But something logs me out between the response to the POST containing my session id and the GET to the authenticated route (which fails because the session associated with the ID is purged between requests). No code change required.

[akomm]

You might stick and load the storage from global variable in development. But it might become stale and cause problems when you change things. As long as dependencies don't change in an incompatible way, this includes also configuration from environment set once on instantiation, there should be no problem.

Example:

// utils/xy.ts or utils/xy.server.ts
export const y = Math.random()

export const x = (() => {
  if ("development" !== process.env.NODE_ENV) {
    return Math.random()
  }

  // names on global should be more distinct...
  const g = global as {x?: number}
  const x = g.x

  if (typeof x !== "number") {
    // Math.random() is your service instantiation
    // If "x" has some dependencies on "a" and "b" (primitive types) you need to track it via global too for changes
    // if (typeof x !== "number" || a !== g?.xOptions?.a || b !== g?.xOptions?.b)  /* recreate both xOptions and x on global */
    return (g.x = Math.random())
  }

  return x
})()

// some route
import {LoaderFunction} from "remix"
import {x, y} from "~/utils/xy.server.ts"

type LoaderData = {x: number; y: number}
export const loader: LoaderFunction = () => json<LoaderData>({x, y})

export default function SomeRoute() {
    const {x, y} = useLoaderData<LoaderData>()
    return (<div>x: {x}, y: {y}</div>)
}

[itacirgabral]

funny warning:

This should only be used in development (...)
https://remix.run/docs/en/v1/utils/sessions#creatememorysessionstorage

But it only works in prod :s

• https://github.com/remix-run/remix/blob/main/packages/remix-server-runtime/sessions/memoryStorage.ts#L35

maybe this code above could be workarounded like the prisma hack
https://remix.run/docs/en/v1/tutorials/jokes#connect-to-the-database

type SessionFactoryMap = Map<string, {
    data: SessionData;
    expires?: Date | undefined;
}>
declare global {
  var __sfm: SessionFactoryMap | undefined;
}

let map: SessionFactoryMap

if (process.env.NODE_ENV === "production") {
  map = new Map<string, { data: SessionData; expires?: Date }>();
} else {
  if (!global.__sfm) {
    global.__sfm = new Map<string, { data: SessionData; expires?: Date }>();
  }
  map = global.__sfm;
}

[akomm]

This is basically my proposal above, but without the notice to track the dependencies. Many copy the workaround proposed for prisma, without realizing that in the other case their instantiation has parameters (dependencies) which might change. If they want them to update, they need to track them in global as well. Otherwise you need to restart the server.

It is not the restart that is a problem, but people confused why something doesn't work, but its simply because they still run with old options passed to the instance.

[mjackson]

This shouldn't be a problem with the v2_dev server since we don't purge modules after every request anymore. With v2_dev, if you don't change your app code, in-memory stuff just works ootb.

Please give this a shot with the v2_dev flag and let us know how it goes 🙏 Thanks!

[github-actions]

This issue has been automatically closed because we haven't received a response from the original author 🙈. This automation helps keep the issue tracker clean from issues that are unactionable. Please reach out if you have more information for us! 🙂