Would allowing a callback for $options['ttl'] make sense?

I guess, but it makes it all more complex and it would only work for php container configs. Plus for my use case it'd really complicate things I think, compared to injecting the Redis handler in another service and modifying it at runtime.

Can you share a bit more about your use case?
We try to avoid making services mutable as much as possible, so I'm looking for alternatives...

Actually, you can already change the ttl at runtime: set the ttl to null when creating the object, and use ini_set when you need a dynamic ttl!

Yeah I tried that but it doesn't work because ini_set prevents you from changing session.gc_maxlifetime once a session is started.

The use case is we have some users which require a longer session lifetime, so we have a request listener changing the session TTL for them, making sure that the SETEX at the session write is done with the correct TTL. We do need to know the user though so we kinda have to do that after the session is started.

What about an immutablewithOptions, to ease decoration per TTL.

I think I'd rather keep my ReflectionProperty hack tbh 😅

It would make more sense to add this method to the Session instance to me.

@nicolas-grekas I am not sure I understand how that would work. Session->setTtl you mean, then how does that call it on the storage? Would need to add setTtl to SessionStorageInterface, and then one would still need a new interface for the handlers themselves to implement as SessionHandlerInterface is native.

Sounds like a lot of mess just for this tiny use case. I could add it as well to MemcachedSessionHandler though for completeness, but other handlers really have no way of changing a TTL at runtime anyway.

What's the status here?@nicolas-grekas?

Closing in favor of#45873