phalcon/cphalcon · error · Phalcon\Container\Exceptions\Exception

Auth {context} requires service. None of the following are b

Error message

Auth {context} requires service. None of the following are bound in the container: {candidates}

What it means

ContainerResolver::requireService() walks an ordered candidate list (usually the service's interface FQN followed by its conventional short name, e.g. SessionInterface then 'session') and returns the first one the container can provide. If none of the candidates is bound, it throws ContainerException listing every name it tried. This powers framework-service lookup for auth guards (request, cookies, session) whose container key varies between applications.

Source

Thrown at phalcon/Auth/Internal/ContainerResolver.zep:70

     * setups.
     *
     * @param list<string> $candidates
     *
     * @throws ContainerException
     */
    public static function requireService(var container, array candidates, string context) -> object
    {
        self::ensureContainer(container);

        var name;

        for name in candidates {
            if (container->has(name)) {
                return self::resolveShared(container, name);
            }
        }

        throw new ContainerException(
            "Auth " . context . " requires service. None of the following are "
            . "bound in the container: " . implode(", ", candidates)
        );
    }

    /**
     * Convenience composition of serviceCandidates() + requireService():
     * resolves the first bound candidate for a framework service whose
     * container key may vary, using the options override or the
     * [interface FQN, conventional short name] fallback.
     *
     * @param array<string, mixed> $options
     *
     * @throws ContainerException
     */
    public static function resolveCandidate(
        var container,
        array options,

View on GitHub (pinned to b7419de9cd)

Solutions

  1. Register the missing service in your DI under its conventional name: $di->set('session', new \Phalcon\Session\Manager(), true) (same for 'cookies', 'request')
  2. Or bind it under the interface FQN: $di->set(\Phalcon\Session\ManagerInterface::class, ...)
  3. Or pass an explicit services override in the guard options, e.g. options: ['services' => ['session' => 'mySession']], so the resolver looks up your custom key first

Example fix

// before
$di = new \Phalcon\Di\Di();
$manager = (new ManagerFactory($hasher, $di))->load($config); // 'session' unbound

// after
$di->set('session', new \Phalcon\Session\Manager(), true);
$manager = (new ManagerFactory($hasher, $di))->load($config);
Defensive patterns

Strategy: validation

Validate before calling

foreach (['session', 'cookies', 'request'] as $svc) {
    if (!$di->has($svc)) {
        throw new RuntimeException("DI is missing the '{$svc}' service required by auth guards");
    }
}

Try / catch

try {
    $manager = (new ManagerFactory($hasher, $di))->load($config);
} catch (\Phalcon\Container\Exceptions\Exception $e) {
    // message lists every candidate name tried; register one of them and retry once at boot
}

Prevention

When it happens

Trigger: Building/using a session guard when the DI has no 'session'/SessionInterface binding; using a guard that needs 'cookies' or 'request' on a freshly constructed Di with no services registered; using the new Phalcon Container without having defined the service.

Common situations: CLI or test bootstrap that creates a bare new Di() and never registers framework services; an application that registers the session under a custom name (e.g. 'mySession') without telling auth; upgrading where the interface FQN candidate changed.

Related errors


AI-assisted analysis of phalcon/cphalcon@b7419de9cd (2026-08-21). Data as JSON: /api/errors/b211f160ce512b61. Report an issue: GitHub.