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

  1. Check errors.Is / err.Equal(sessions.ErrNotImplemented) and treat expiration updates as a no-op for that backend.
  2. Choose a backend that supports expiration updates (e.g. Redis-based) if TTL refresh is required.
  3. Implement OnUpdateExpiration in your custom Database by rewriting the record with a new TTL.
  4. 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

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


AI-assisted analysis of kataras/iris@7bedaf55a0 (2026-08-30). Data as JSON: /api/errors/8e300cd804a37b2e. Report an issue: GitHub.