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

Cannot resolve a fresh '{name}': it is not bound in the cont

Error message

Cannot resolve a fresh '{name}': it is not bound in the container

What it means

ContainerResolver::resolveFresh() resolves a NEW (non-shared) instance of a service. When the container is the new Phalcon Container (a Service Collection), there is no autowiring fallback: the service must already be bound. If the collection has no binding for the requested name, this ContainerException is thrown. Contrast with the legacy Di branch (error 46), which additionally allows unregistered-but-existing classes.

Source

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

    }

    /**
     * Resolves a fresh instance: new() on the Container (bypasses the
     * instance cache); get() on the legacy Di (fresh for unregistered or
     * non-shared services). On Di, an unregistered but existing class is
     * still built via the class builder.
     *
     * @throws ContainerException
     */
    public static function resolveFresh(var container, string name) -> object
    {
        var e;

        self::ensureContainer(container);

        if (container instanceof Collection) {
            if (true !== container->has(name)) {
                throw new ContainerException(
                    "Cannot resolve a fresh '" . name
                    . "': it is not bound in the container"
                );
            }

            return container->{"new"}(name);
        }

        if (true !== container->has(name) && !class_exists(name)) {
            throw new ContainerException(
                "Cannot resolve a fresh '" . name
                . "': it is not registered in the Di and is not an existing class"
            );
        }

        try {
            return container->get(name);
        } catch DiException, e {

View on GitHub (pinned to b7419de9cd)

Solutions

1. Register the service in the Container collection under the exact name being resolved before requesting a fresh instance
2. If you relied on legacy Di's build-any-existing-class behavior, keep using a DiInterface container for that resolution
3. Double-check for name mismatches/typos between the binding key and the requested name

Example fix

// before
$container = new \Phalcon\Container\Container();
// nothing bound under 'streamAdapter'

// after
$container->set('streamAdapter', \Phalcon\Auth\Adapter\Stream::class);

if ($container instanceof \Phalcon\Contracts\Container\Service\Collection && !$container->has($name)) {
    throw new RuntimeException("'{$name}' must be bound in the Container before fresh resolution");
}

try {
    $instance = $resolverFreshPath; // whatever triggers resolveFresh
} catch (\Phalcon\Container\Exceptions\Exception $e) {
    // bind the service and retry; no autowiring fallback exists on Collection
}

When it happens

Trigger: Calling resolveFresh($collection, 'guard-name') (directly, or via Auth internals that build fresh guard/adapter instances) against a Phalcon Container collection in which that name was never registered.

Common situations: Migrating from legacy Di to the new Container and assuming the class-builder fallback still applies; constructing guards lazily while forgetting to define them in the Container; name typos between the definition and the lookup.

Related errors

• Auth {context} requires service. None of the following are b
• The parameter must be an instance of Collection or DiInterfa
• Cannot resolve a fresh '{name}': it is not registered in the
• Failed to resolve '{name}' from the Di container
• Malformed ACL snapshot structure

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