resave error

[decifris]

Hello, I edited the session and I got this error, precisely I edited the "resave" property, this is the session:
app.use( session({ secret: "secret", resave: true, saveUninitialized: false, cookie: { maxAge: 20 * 1000, }, store: new PrismaSessionStore(new PrismaClient(), { checkPeriod: 2 * 60 * 1000, //ms dbRecordIdIsSessionId: true, dbRecordIdFunction: undefined, }), }), );

This is the error:

'(node:2280) UnhandledPromiseRejectionWarning: Error: 
Invalid 'this.prisma[this.sessionModelName].update()' invocation in
C:\Users\latta\Documents\GitHub\students-backend\parriot-backend\node_modules\@quixo3\prisma-session-store\dist\lib\prisma-session-store.js:483:81  

  480     id: this.dbRecordIdIsSessionId ? sid : this.dbRecordIdFunction(sid),
  481 };
  482 if (!(existingSession !== null)) return [3 /*break*/, 4];
→ 483 return [4 /*yield*/, this.prisma[this.sessionModelName].update({
        data: {
          sid: 'BDTh4UWzc3-XHbGvqsroree_tky1gV68',
          expiresAt: new Date('2022-05-07T20:36:14.216Z'),
          data: '{"cookie":{"originalMaxAge":20000,"expires":"2022-05-07T20:36:14.216Z","httpOnly":true,"path":"/"},"passport":{"user":{"id":"625dea792235a00bc2a6da99","createdAt":"2022-04-18T22:47:21.021Z","updatedAt":"2022-04-18T22:47:21.023Z","email":"test1@t.co","firstName":null,"lastName":null,"verified":null}}}',
          id: 'BDTh4UWzc3-XHbGvqsroree_tky1gV68'
          ~~
        },
        where: {
          sid: 'BDTh4UWzc3-XHbGvqsroree_tky1gV68'
        }
      })

Unknown arg 'id' in data.id for type SessionUpdateInput. Did you mean 'sid'? Available args:
type SessionUpdateInput {
  sid?: String | StringFieldUpdateOperationsInput
  data?: String | StringFieldUpdateOperationsInput
  expiresAt?: DateTime | DateTimeFieldUpdateOperationsInput
}


    at Object.validate (C:\Users\latta\Documents\GitHub\students-backend\parriot-backend\node_modules\@prisma\client\runtime\index.js:44425:20)     
    at PrismaClient._executeRequest (C:\Users\latta\Documents\GitHub\students-backend\parriot-backend\node_modules\@prisma\client\runtime\index.js:46509:17)
    at consumer (C:\Users\latta\Documents\GitHub\students-backend\parriot-backend\node_modules\@prisma\client\runtime\index.js:46453:23)
    at C:\Users\latta\Documents\GitHub\students-backend\parriot-backend\node_modules\@prisma\client\runtime\index.js:46457:76
    at runInChildSpan (C:\Users\latta\Documents\GitHub\students-backend\parriot-backend\node_modules\@prisma\client\runtime\index.js:45702:12)      
    at C:\Users\latta\Documents\GitHub\students-backend\parriot-backend\node_modules\@prisma\client\runtime\index.js:46457:20
    at AsyncResource.runInAsyncScope (async_hooks.js:197:9)
    at PrismaClient._request (C:\Users\latta\Documents\GitHub\students-backend\parriot-backend\node_modules\@prisma\client\runtime\index.js:46456:86)
    at C:\Users\latta\Documents\GitHub\students-backend\parriot-backend\node_modules\@prisma\client\runtime\index.js:43088:25
    at _callback (C:\Users\latta\Documents\GitHub\students-backend\parriot-backend\node_modules\@prisma\client\runtime\index.js:42852:52)
(Use 'node --trace-warnings ...' to show where the warning was created)
(node:2280) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag '--unhandled-rejections=strict' (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:2280) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

[kleydon]

Hi @decifris,

Thanks for posting this.

I've just posted a new release (3.1.4) that will prevent a crash in this circumstance, while still allowing the error to surface and be accessed via a callback function parameter (see notes for issue #82, here).

However, the underlying cause of the specific crash above remains unclear... From the log output, it looks like Prisma is complaining about an id parameter being supplied as part of update()'s data field, but id (I believe?) should be a legal parameter here.

• Perhaps prisma's supplied "Unknown arg 'id' in data.id for type SessionUpdateInput." message is in error?

• Perhaps type SessionUpdateInput is (somehow, somewhere - perhaps by a prisma generator?) being defined improperly in a way that is excluding id?

• Perhaps the parameters supplied to update() are malformed in some way (bad json?) that is causing a parse error that is incorrectly suggesting that id is a problem?

• Is this an issue you can reproduce reliably - or something that has happened once or intermittently?

I'm guessing the underlying issue is a prisma (or prisma generator?) issue, but - not certain.

Will leave this open for a bit, to see if new knowledge accumulates...

[SunburntRock89]

I don't have any particular new knowledge, but I can repro this issue. I always figured this was a purposeful thing (unable to edit the @id field of an object to prevent you from breaking things), I can provide more information if needed.

It is possible that the outcome changes depending on which database provider you are using?

[SunburntRock89]

What I have found is that if you define your model in such a way that id and sid are unique, but neither are the table's primary key, the library performs as expected, at least in being able to bypass this error, will continue to monitor.

model Session {
  objId     String   @id @map("_id") @db.ObjectId @default(auto())
  id        String   @unique
  sid       String   @unique
  data      String
  expiresAt DateTime
}

[kleydon]

@SunburntRock89 - thanks for the info.

It is possible that the outcome changes depending on which database provider you are using?

I've mainly used postgres - so not sure about this... Are you seeing this with a db other than postgres?

What I have found is that if you define your model in such a way that id and sid are unique, but neither are the table's primary key, the library performs as expected, at least in being able to bypass this error, will continue to monitor.

Good to know; thanks for this "clue".

[SunburntRock89]

I've mainly used postgres - so not sure about this... Are you seeing this with a db other than postgres?

Apologies, didn't get an email about this.
Probably should've mentioned that I experienced this using Mongo, haven't tried any other DBs.

[SunburntRock89]

Alright so after some minor digging I've discovered that this is specifically a Mongo issue.
_id is an immutable field and as such the generator does not allow you to edit it with .update

When attempting to modify _id in Studio 3T

Mongo Server error (MongoWriteException): Write operation error on server (my-atlas-instance). Write error: WriteError{code=66, message='After applying the update, the (immutable) field '_id' was found to have been altered to _id: 2', details={}}.

The big key here is the (immutable) field '_id'.

I'm not 100% on the architecture of this library, but does the id field absolutely need to be edited?

[kleydon]

I'm not 100% on the architecture of this library, but does the id field absolutely need to be edited?

I'm 99.9% sure it shouldn't be - at least, it shouldn't be without also changing sid, so that dbRecordIdFunction() consistently maps one to the other.

Good idea (I think) to make id non-updateable.

I believe the fix (PR #96) addresses this bug; closing for now.