Closed decifris closed 1 year ago
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...
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?
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
}
@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".
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.
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?
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.
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: