miniflare icon indicating copy to clipboard operation
miniflare copied to clipboard

instanceof Date fails when round-tripping through DO storage

Open vlovich opened this issue 3 years ago • 3 comments

Might be related to using Sinon.JS but I'm noticing that if I store a Date object within a DO entry and then retrieving it, the retrieved date no longer satisfies instanceof Date.

await storage.put('somekey', {
  someKey: {
    someDate: new Date()
  }
})
const result = await storage.get('somekey')
if (!(result.someKey.someDate instanceof Date)) {
   throw new Error('Looks like a Date, quacks like a Date but not a Date')
}

The workaround I've found is:

function isDateInstance(value: any): value is Date {
    return value instanceof Date || (typeof value === 'object' && value.constructor.name === 'Date')
}

This is mildly annoying because this code isn't easy to dead code strip (https://github.com/evanw/esbuild/issues/2061).

vlovich avatar Feb 27 '22 01:02 vlovich

Noticing this for more than just date. For example, if I grab an object like

{
  foo: {
    bar: {},
    car: [],
  }
}

from the DO storage, Jest will fail expect(retrieved.foo).toStrictEqual({ bar: {}, car: [] }) because one of it's matchers is validating that the both sides have the same constructor (this worked correctly in Miniflare 1.4).

vlovich avatar Feb 27 '22 09:02 vlovich

Hey! 👋 This is pretty strange. Date should be passed in the parent Node.js context... https://github.com/cloudflare/miniflare/blob/b887877810a745f2a458d20da0a3dbd9f8a58cf4/packages/core/src/plugins/core.ts#L460 ...so it should be the same Date object in the sandbox as outside. This will be grabbed when you initialise a new Miniflare instance though, so if you enable fake timers after that, maybe the class is different? Could try await mf.setOptions({ globals: { Date } }) after you enable fake timers?

mrbbot avatar Mar 04 '22 20:03 mrbbot

It's not just happening to Date objects but I'll try.

vlovich avatar Mar 04 '22 21:03 vlovich

Hey! 👋 I'm going to close this as it's unlikely we'll have time to fix this in Miniflare 2. Our development effort is primarily focused on version 3. Miniflare 3 increases the gap between Node.js and workerd making it tricky to end up in this kind of situation. We're planning on revamping the Vitest environment for Miniflare 3 soon too, running tests entirely in workerd which should also help with this.

mrbbot avatar Nov 07 '23 15:11 mrbbot