add is memory token property to sessions

[udaraweerasinghege]

#2002

[vladikoff]

@udaraweerasinghege Do you need to undo this change?

[vladikoff]

@udaraweerasinghege we also need to update the response schemas for /sessions and /devices, to handle this optional property. I'm hoping API.md will auto update with this

[rfk]

With appologies for the late drive-by comment, this seems like it's piercing a layer of abstraction - it's taking an internal implementation detail of the server and exposing it in the API for consumption by the client. To display the correct information, the content-server needs to know that the auth-server sometimes stores tokens in redis, and that these tokens are the only ones that are up-to-date.

I wonder if a better abstraction here would involve us sending two separate timestamps:

• lastAccessTime: the value from redis, but it might be null if we don't have a correct value to show
• createdTime: the "started syncing" timestamp which we know we can always get from the db

[vladikoff]

I wonder if a better abstraction here would involve us sending two separate timestamps

Yeah we had that idea earlier, but I Think @philbooth wanted to keep the fields from redis and mysql consistent (to avoid confusion, etc)

[vladikoff]

from mtg:

lastAccessTimeFormatted - redis token
createdTimeFormatted - created token

[philbooth]

Yeah we had that idea earlier, but I Think @philbooth wanted to keep the fields from redis and mysql consistent (to avoid confusion, etc)

Fwiw, I just checked with @philbooth and he's +1 to @rfk's suggestion. 😄

The consistency comment concerned whether session tokens returned from redis should also include data that was fetched from MySQL, IIRC. I see no conflict here.