Argument #1 passed to function `is_string` has type `never`, meaning it cannot produce a value. >This argument expression results in type `never` The `never` type means no value can reach this point at runtime - this code path is unreachable. This often occurs in unreachable code, due to impossible conditional logic, or if an expression always exits (e.g., `throw`, `exit()`). Help: Review preceding logic to ensure this argument can receive a value, or remove if unreachable.

Cannot return value with type 'never' from this function. >This expression has type 'never'. >This return statement is effectively unreachable. A 'never' return type indicates that a function is guaranteed to exit the script, throw an exception, or loop indefinitely. Code following a call to such a function is unreachable. Help: Since the preceding expression never returns, this 'return' statement cannot be reached. You can likely remove the 'return' keyword entirely.

Method `create` does not exist on type `Symfony\Component\HttpClient\HttpClient`. >This method selection is invalid >This expression has type `Symfony\Component\HttpClient\HttpClient` Help: Ensure the `create` method is defined in the `Symfony\Component\HttpClient\HttpClient` class-like.

Class `Symfony\Component\HttpClient\Psr18Client` not found. >`Symfony\Component\HttpClient\Psr18Client` is not defined or cannot be autoloaded Help: Ensure the name is correct, including its namespace, and that it's properly defined and autoloadable.

Cannot find class, interface, enum, or type alias `Psr\Http\Client\ClientInterface`. >`Psr\Http\Client\ClientInterface` is not defined in the current codebase This error occurs when a type is referenced but not found in any analyzed source files or stubs. If this type comes from an optional dependency or extension, you can safely suppress this issue using `@mago-ignore` or `@mago-expect`. Help: Verify the type name is spelled correctly, the file containing it is included in analysis, and any required `use` statements are present.

Could not infer a precise return type for function `OpenTelemetry\SDK\Common\Configuration\Configuration::getType`. Saw type `mixed`. >Type inferred as `mixed` here. The analysis could not determine a specific type for the value returned here, resulting in `mixed`. This can happen with complex code paths or unannotated data. Help: Add specific type hints to variables, parameters, or properties involved in calculating the return value. Consider adding a specific return type declaration to the function signature to catch potential mismatches earlier.

Could not infer a precise return type for function `OpenTelemetry\SDK\Common\Configuration\Configuration::getKnownValues`. Saw type `mixed`. >Type inferred as `mixed` here. The analysis could not determine a specific type for the value returned here, resulting in `mixed`. This can happen with complex code paths or unannotated data. Help: Add specific type hints to variables, parameters, or properties involved in calculating the return value. Consider adding a specific return type declaration to the function signature to catch potential mismatches earlier.

Invalid argument type for argument #1 of `OpenTelemetry\SDK\Common\Configuration\Parser\ListParser::parse`: expected `array<array-key, mixed>|string`, but found `mixed`. >Argument has type `mixed` >Arguments to this method are incorrect The type `mixed` is too general and does not match the expected type `array<array-key, mixed>|string`. Help: Add specific type hints or assertions to the argument value.

Invalid argument type for argument #2 of `sprintf`: expected `Stringable|null|scalar`, but found `mixed`. >Argument has type `mixed` >Arguments to this function are incorrect The type `mixed` is too general and does not match the expected type `Stringable|null|scalar`. Help: Add specific type hints or assertions to the argument value.

Invalid argument type for argument #1 of `OpenTelemetry\SDK\Common\Configuration\Parser\BooleanParser::parse`: expected `bool|string`, but found `mixed`. >Argument has type `mixed` >Arguments to this method are incorrect The type `mixed` is too general and does not match the expected type `bool|string`. Help: Add specific type hints or assertions to the argument value.

Class has high complexity. >Class has a cyclomatic complexity of 17, which exceeds the threshold of 15.

Use of the `empty` construct. >Ambiguous check due to `empty()` loose semantic `empty()` exhibits unexpected behavior on specific value. It is unclear what condition is being treated with `empty()`. Help: Use strict comparison or specific predicate function to clearly convey your intent.

Unsafe use of error control operator `@`. >This operator suppresses errors >This expression is being suppressed Error control operator hide potential errors and make debugging more difficult. Help: Remove the `@` and use `set_error_handler` to handle errors instead.

Class has too many methods. >Class has 13 methods, which exceeds the threshold of 10. Having a large number of methods can make structures harder to understand and maintain. Help: Try reducing the number of methods, or consider splitting the structure into smaller, more focused structures.

Class has a high kan defect score. >Class has a kan defect score of 4.73, which exceeds the threshold of 1.6. Kan defect is a heuristic used by phpmetrics to estimate defect-proneness based on control-flow statements. Help: You can also consider splitting large units of code into smaller, more focused units.

Class has high complexity. >Class has a cyclomatic complexity of 57, which exceeds the threshold of 15.

Class has too many methods. >Class has 15 methods, which exceeds the threshold of 10. Having a large number of methods can make structures harder to understand and maintain. Help: Try reducing the number of methods, or consider splitting the structure into smaller, more focused structures.

Class has high complexity. >Class has a cyclomatic complexity of 31, which exceeds the threshold of 15.

Parameter list is too long. >This list has 6 parameters, which exceeds the threshold of 5. Having a large number of parameters can make functions harder to understand and maintain. Help: Try reducing the number of parameters, or consider passing an object or a shape instead.

Class has too many methods. >Class has 16 methods, which exceeds the threshold of 10. Having a large number of methods can make structures harder to understand and maintain. Help: Try reducing the number of methods, or consider splitting the structure into smaller, more focused structures.

Process completed with exit code 1.

Assigning `mixed` type to a variable may lead to unexpected behavior. >Assigning `mixed` type here. Using `mixed` can lead to runtime errors if the variable is used in a way that assumes a specific type. Help: Consider using a more specific type to avoid potential issues.

Assigning `mixed` type to a variable may lead to unexpected behavior. >Assigning `mixed` type here. Using `mixed` can lead to runtime errors if the variable is used in a way that assumes a specific type. Help: Consider using a more specific type to avoid potential issues.

Assigning `mixed` type to a variable may lead to unexpected behavior. >Assigning `mixed` type here. Using `mixed` can lead to runtime errors if the variable is used in a way that assumes a specific type. Help: Consider using a more specific type to avoid potential issues.

Redundant type assertion: `$factory` of type `never` is always not `string`. >Argument `$factory` has type `never` The assertion expects `$factory` to not be `string`, which is always true. Help: Consider removing this assertion as it has no effect.

Redundant type assertion: `$factory` of type `never` is always not `string`. >Argument `$factory` has type `never` The assertion expects `$factory` to not be `string`, which is always true. Help: Consider removing this assertion as it has no effect.

Redundant type assertion: `$factory` of type `never` is always not `string`. >Argument `$factory` has type `never` The assertion expects `$factory` to not be `string`, which is always true. Help: Consider removing this assertion as it has no effect.

Redundant type assertion: `$factory` of type `never` is always not `string`. >Argument `$factory` has type `never` The assertion expects `$factory` to not be `string`, which is always true. Help: Consider removing this assertion as it has no effect.

Casting `mixed` to `float`. >This expression has type `mixed` The float value of `mixed` cannot be determined statically. The result will be a general `float`. Help: Consider adding type assertions or checks if a more specific float outcome is expected.

Assigning `mixed` type to a variable may lead to unexpected behavior. >Assigning `mixed` type here. Using `mixed` can lead to runtime errors if the variable is used in a way that assumes a specific type. Help: Consider using a more specific type to avoid potential issues.

TODO should be tagged with (@username) or (#issue). >TODO comment is untagged Help: Add a user tag or issue reference to the TODO comment, e.g. TODO(@azjezz), TODO(azjezz), TODO(#123).

TODO should be tagged with (@username) or (#issue). >TODO comment is untagged Help: Add a user tag or issue reference to the TODO comment, e.g. TODO(@azjezz), TODO(azjezz), TODO(#123).

TODO should be tagged with (@username) or (#issue). >TODO comment is untagged Help: Add a user tag or issue reference to the TODO comment, e.g. TODO(@azjezz), TODO(azjezz), TODO(#123).

TODO should be tagged with (@username) or (#issue). >TODO comment is untagged Help: Add a user tag or issue reference to the TODO comment, e.g. TODO(@azjezz), TODO(azjezz), TODO(#123).

Missing description in assert function. >`assert` function is called here Assert functions should have a description to make it easier to understand the purpose of the assertion. Help: Add a description to the assert function to clarify its purpose.

Missing description in assert function. >`assert` function is called here Assert functions should have a description to make it easier to understand the purpose of the assertion. Help: Add a description to the assert function to clarify its purpose.

Missing description in assert function. >`assert` function is called here Assert functions should have a description to make it easier to understand the purpose of the assertion. Help: Add a description to the assert function to clarify its purpose.

Missing description in assert function. >`assert` function is called here Assert functions should have a description to make it easier to understand the purpose of the assertion. Help: Add a description to the assert function to clarify its purpose.

Missing description in assert function. >`assert` function is called here Assert functions should have a description to make it easier to understand the purpose of the assertion. Help: Add a description to the assert function to clarify its purpose.

Nested ternary expressions are confusing due to PHP's operator associativity rules. >This is the nested ternary operation >It is nested inside this outer ternary operator The ternary operator `? :` is non-associative in PHP 8+, was left-associative before, and is right-associative in most other languages. This can lead to unexpected behavior, and even with parentheses, it can be hard to read and understand. Help: Consider refactoring the logic into a separate `if/else` statement or a `match` expression for clarity.

Avoid `else` clauses. >This `else` clause can often be eliminated Code is often clearer when the main logic is not nested inside an `if` statement. Help: Consider refactoring to use an early return (a guard clause) to simplify the control flow.

Avoid boolean flag parameters. >This parameter acts as a boolean flag >Boolean type declared here Boolean flags often indicate a function has more than one responsibility, making it harder to understand and test. Help: Refactor by splitting the function into two separate methods, each with a clear, descriptive name.

Avoid boolean flag parameters. >This parameter acts as a boolean flag >Boolean type declared here Boolean flags often indicate a function has more than one responsibility, making it harder to understand and test. Help: Refactor by splitting the function into two separate methods, each with a clear, descriptive name.

Avoid boolean flag parameters. >This parameter acts as a boolean flag >Boolean type declared here Boolean flags often indicate a function has more than one responsibility, making it harder to understand and test. Help: Refactor by splitting the function into two separate methods, each with a clear, descriptive name.

Avoid boolean flag parameters. >This parameter acts as a boolean flag >Boolean type declared here Boolean flags often indicate a function has more than one responsibility, making it harder to understand and test. Help: Refactor by splitting the function into two separate methods, each with a clear, descriptive name.

Avoid boolean flag parameters. >This parameter acts as a boolean flag >Boolean type declared here Boolean flags often indicate a function has more than one responsibility, making it harder to understand and test. Help: Refactor by splitting the function into two separate methods, each with a clear, descriptive name.

Avoid boolean flag parameters. >This parameter acts as a boolean flag >Boolean type declared here Boolean flags often indicate a function has more than one responsibility, making it harder to understand and test. Help: Refactor by splitting the function into two separate methods, each with a clear, descriptive name.

Avoid boolean flag parameters. >This parameter acts as a boolean flag >Boolean type declared here Boolean flags often indicate a function has more than one responsibility, making it harder to understand and test. Help: Refactor by splitting the function into two separate methods, each with a clear, descriptive name.

Avoid boolean flag parameters. >This parameter acts as a boolean flag >Boolean type declared here Boolean flags often indicate a function has more than one responsibility, making it harder to understand and test. Help: Refactor by splitting the function into two separate methods, each with a clear, descriptive name.