kataras/iris · info
not implemented yet
Error message
not implemented yet
What it means
sessions.ErrNotImplemented is returned by the sessions Database interface for features a specific database backend does not support, notably OnUpdateExpiration on backends that cannot reset TTLs. The docs suggest matching it directly with sessions.ErrNotImplemented.Equal(err).
Source
Thrown at sessions/database.go:17
package sessions
import (
"errors"
"reflect"
"sync"
"time"
"github.com/kataras/iris/v12/context"
"github.com/kataras/iris/v12/core/memstore"
"github.com/kataras/golog"
)
// ErrNotImplemented is returned when a particular feature is not yet implemented yet.
// It can be matched directly, i.e: `isNotImplementedError := sessions.ErrNotImplemented.Equal(err)`.
var ErrNotImplemented = errors.New("not implemented yet")
// Database is the interface which all session databases should implement
// By design it doesn't support any type of cookie session like other frameworks.
// I want to protect you, believe me.
// The scope of the database is to store somewhere the sessions in order to
// keep them after restarting the server, nothing more.
//
// Synchronization are made automatically, you can register one using `UseDatabase`.
//
// Look the `sessiondb` folder for databases implementations.
type Database interface {
// SetLogger should inject a logger to this Database.
SetLogger(*golog.Logger)
// Acquire receives a session's lifetime from the database,
// if the return value is LifeTime{} then the session manager sets the life time based on the expiration duration lives in configuration.
Acquire(sid string, expires time.Duration) memstore.LifeTime
// OnUpdateExpiration should re-set the expiration (ttl) of the session entry inside the database,
// it is fired on `ShiftExpiration` and `UpdateExpiration`.View on GitHub (pinned to 7bedaf55a0)
Solutions
- Check errors.Is / err.Equal(sessions.ErrNotImplemented) and treat expiration updates as a no-op for that backend.
- Choose a backend that supports expiration updates (e.g. Redis-based) if TTL refresh is required.
- Implement OnUpdateExpiration in your custom Database by rewriting the record with a new TTL.
- Recreate/expire sessions manually based on your storage's native TTL mechanism.
Example fix
// before
err := db.OnUpdateExpiration(sid, newLifetime) // panics flow assumes always supported
// after
if err := db.OnUpdateExpiration(sid, newLifetime); err != nil && !errors.Is(err, sessions.ErrNotImplemented) {
return err // ignore only the not-implemented case
} Defensive patterns
Strategy: type-guard
Type guard
func supportsExpirationUpdate(db sessions.Database) bool {
return !errors.Is(db.OnUpdateExpiration("probe", 1*time.Minute), sessions.ErrNotImplemented)
} Try / catch
if err := db.OnUpdateExpiration(sid, lt); err != nil && errors.Is(err, sessions.ErrNotImplemented) {
// backend ignores TTL updates — treat as no-op
err = nil
} Prevention
- Check backend feature support before switching session storage.
- Wrap optional Database methods with not-implemented checks.
- Pin backend selection to requirements (TTL refresh vs simple KV).
When it happens
Trigger: Calling db.OnUpdateExpiration(...) on a session database (e.g. a custom or basic backend) that has not implemented expiration updates; the method's default/implementing body returns this sentinel.
Common situations: Switching session storage backends (memory -> badger/boltdb/redis) and assuming all expose expiration updates; writing a custom sessions.Database that leaves optional methods unimplemented.
Related errors
- session not found
- directoryPath is empty
- path is required
- compress: response will not be compressed
- empty form
AI-assisted analysis of kataras/iris@7bedaf55a0 (2026-08-30).
Data as JSON: /api/errors/8e300cd804a37b2e.
Report an issue: GitHub.