Inserting forces a sesssion read which could cause the insert to error

[Zatzou]

When inserting data to the session the .insert() function reads the previously stored data before inserting the new data. While this generally is not an issue issues may arise if bad data gets saved into the session.

However, if the read errors with a decode error the new data ends up never getting inserted and instead the insert function just errors on decoding the old data.

Generally I think the insert function should either ignore possible decode issues or there should be an insert function which doesnt even attempt to read the previous session.

The same issue also kind of applies to .remove() as it also reads the previous value which means that

[maxcountryman]

However, if the read errors with a decode error

Specifically this is referring to load failing, yes?

Corrupt session data is a state that we leave up the store implementation to define behavior for.

As an example, a store could look for decode errors and then decide to clear the store or reset the bad record entry and proceed without bubbling the error up to the caller. The session store API boundary intentionally leaves these kinds of decisions up the implementer because we don't want to be too opinionated about what semantics will best suite a particular use case.

Taking a step back, our design borrows heavily from Django's, which also loads upon insert (in fact, this happens whenever the underlying dict is referenced, via Python's magic methods).

[maxcountryman]

I do also feel that having just some way to force a new insert replacing the old data would be useful.

It's not clear what this would mean: if the store is unreachable or the session data has become corrupt we're in serious trouble. This situation is so dire that in most cases applications will want to stop completely because normal operation is not possible and there's no way to recover.

Mainly I feel like it would just plain be useful to have additional methods which just insert and remove without even trying to read the old state.

The trouble here is now we need to worry about merge semantics which implies that we need to load anyway.

If we don't load at all before saving then we need to pass stores partial records and stores would have to contend with merging before saving--we haven't really saved a load here (we'll need to load before merging generally speaking), we've just hidden it in the save method. This also introduces an insidious failure mode: if stores are unaware that they've received a partial record and they save the record as though it's complete they can inadvertently remove data from the store without intending to (by saving the record as though it's complete when it's missing data that was already in the store).

Furthermore in situations where we insert and then get, the session manager would need to also manage merges.

That said, I'm open to ideas that don't complicate the contract with session stores.

[Zatzou]

yea I see actually I was very wrong here. So I had somehow convinced myself that the library stored each session item as its own item but obviously reading thru the things again I have no idea how I came to that conclusion. (I guess record to me sounded like it would be a singular record rather than all of the records within the session, and I didnt notice the hashmap in there somehow)

Also yea I dont think this is as much of an issue anymore since I think the reason I kept getting this issue for a bit was just due to me experimenting with multiple serializers.

But yea with how things are this stance does definitely make sense since modifying the session without loading the previous session would clearly just delete any existing data or require the store to do complex merges.