phalcon/cphalcon · error · UnknownServiceType
Unknown service type in parameter on position {}
Error message
Unknown service type in parameter on position {} What it means
Thrown by Phalcon\Di\Service\Builder::buildParameter() when an argument's 'type' is not one of the three supported strings: 'service', 'parameter', 'instance'. The switch falls through to default and raises UnknownServiceType for the offending position.
Source
Thrown at phalcon/Di/Service/Builder.zep:259
if fetch instanceArguments, argument["arguments"] {
/**
* Build the instance with arguments
*/
return container->get(name, instanceArguments);
}
/**
* The instance parameter does not have arguments for its
* constructor
*/
return container->get(name);
default:
/**
* Unknown parameter type
*/
throw new UnknownServiceType(position);
}
}
/**
* Resolves an array of parameters
*/
private function buildParameters(<DiInterface> container, array arguments) -> array
{
var position, argument;
array buildArguments;
let buildArguments = [];
for position, argument in arguments {
let buildArguments[] = this->buildParameter(
container,
position,
argumentView on GitHub (pinned to b7419de9cd)
Solutions
- Correct the type to exactly 'service', 'parameter', or 'instance' (lowercase, no extra whitespace).
- After a Phalcon 3 -> 5 upgrade, sweep all definitions for 'class' type entries and replace with 'instance' plus 'className'.
- If definitions come from config files, trim/normalize type strings before registering them.
Example fix
// before
'arguments' => [
['type' => 'paramater', 'value' => 10], // typo
],
// after
'arguments' => [
['type' => 'parameter', 'value' => 10],
], Defensive patterns
Strategy: validation
Validate before calling
const DI_ARGUMENT_TYPES = ['service', 'parameter', 'instance'];
function normalizeDiArguments(array $arguments): array
{
foreach ($arguments as $i => &$arg) {
$type = trim((string)($arg['type'] ?? ''));
if (!in_array($type, DI_ARGUMENT_TYPES, true)) {
throw new InvalidArgumentException("Argument {$i}: unknown type '{$type}'");
}
$arg['type'] = $type;
}
return $arguments;
} Type guard
function isKnownArgumentType(mixed $arg): bool
{
return is_array($arg) && in_array(trim((string)($arg['type'] ?? '')), ['service', 'parameter', 'instance'], true);
} Try / catch
try {
$service = $di->get('foo');
} catch (\Phalcon\Di\Exceptions\UnknownServiceType $e) {
$logger->error('DI definition has an invalid type: ' . $e->getMessage());
throw $e;
} Prevention
- Normalize (trim + lowercase) type strings from external config before registering definitions.
- After major Phalcon upgrades, re-run your DI smoke test; the type vocabulary is version-stable but migrations from 3.x reintroduce 'class'.
When it happens
Trigger: A typo in the type string: 'service ' (trailing space), 'instance ', 'paramater', 'value', 'string', 'scalar', 'class' (Phalcon 3 name), or a non-string value. Thrown at resolve time of the service whose definition contains it.
Common situations: Upgrading Phalcon 3 -> 4/5 and keeping 'type' => 'class'; definitions loaded from YAML/JSON where casing or whitespace differs ('Parameter' vs 'parameter'); translating definitions from another DI container's vocabulary.
Related errors
- Argument at position {} must have a type
- Service '{}' is required in parameter on position {}
- Service 'value' is required in parameter on position {}
- Service 'className' is required in parameter on position {}
- A dependency injection container is required to access the '
AI-assisted analysis of phalcon/cphalcon@b7419de9cd (2026-08-21).
Data as JSON: /api/errors/24d5973eccf8056d.
Report an issue: GitHub.