>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3619891. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !83 >>> <h3>Problem/Motivation</h3> <p><span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/pdv/-/work_items/3618633" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/pdv/-/work_items/3618633</a></span> shipped the project's own phpstan.neon and took static analysis from the Drupal Association default of level 0 to level 3, with no baseline and a single ignore pattern for new static(). Level 3 is the level that catches a docblock lying about an array shape. It is not the level that catches a call handing a method the wrong object: that is level 5.</p> <p>Measured against 1.x with the project's own configuration, the ladder above level 3 is short. Level 4 reports 38 findings, level 5 reports 41. Three findings separate the two levels, and two of them are the same runtime crash.</p> <h3>The crash only level 5 sees</h3> <p>VaultOptionsTrait offers two option builders that take different services: getConsumerOptions() takes an EntityTypeManagerInterface, getKindOptions() takes an ItemKindRepository. RequestAccessForm and StoreRequestForm in pdv_consumer_console call them on consecutive lines and pass the entity type manager to both, so getKindOptions() is handed a service with no getAvailableInCurrentTenant() method. The parameter is typed, so buildForm() raises a TypeError and both developer console routes are a white screen.</p> <p>pdv_consumer_console is hidden and dev-only and carries no test coverage, which is why nothing has reported this. Level 4 does not see it; level 5 sees it on both forms. That is the argument for going to 5 rather than stopping at 4.</p> <h3>What else the two levels report</h3> <ul> <li>16 instanceof.alwaysTrue. The entityMapping shipped in phpstan.neon tells the analyzer which class each storage hands back, so guards written when load() answered an EntityInterface are now provably redundant. They are in VaultController, three confirmation forms, GarbageCollector, ItemKindRepository and PdvTenantContext.</li> <li>14 method.alreadyNarrowedType. Test assertions on a type the signature already guarantees, mostly assertInstanceOf() on a controller return typed RedirectResponse.</li> <li>resolveForRead() documents SubjectKeyMissingException but not the VaultLockedException its resolveUnlocked() path throws. That makes SubjectPassphraseTest's catch of it read as a dead catch and everything after it as unreachable, so the second half of testLockGuard() is never analyzed.</li> <li>Vault injects a TimeInterface it never reads.</li> <li>Vault::purgeUser() guards a concrete PdvGrantRequest with method_exists($request, 'getFile').</li> <li>VaultUnlockController::finish() repeats a null test on the pending state that the fail-closed guard above it has already excluded.</li> <li>Six single findings: a negated expression and a right-hand operand that are always true, an array the analyzer proves empty because an event subscriber writes the property indirectly, and the assertion on that array.</li> </ul> <h3>Proposed resolution</h3> <p>Set level 5 in phpstan.neon and fix all 41. No baseline, and no new ignoreErrors entry: a baseline is a level nobody meets, written down, which is the reasoning phpstan.neon already carries.</p> <p>Fix the two forms by passing the item kind repository, and add the kernel coverage that would have caught it, because a hidden submodule with no tests is how a typed parameter went unchecked in the first place. Complete the resolveForRead() docblock rather than deleting the test's catch, since the exception is real and the docblock is what is wrong. Delete the redundant guards, the unread service and the always-true operands rather than annotating around them.</p> <h3>Remaining tasks</h3> <ul> <li>Raise the level in phpstan.neon.</li> <li>Fix the two pdv_consumer_console forms and cover both routes with a kernel test.</li> <li>Fix the remaining 39 findings.</li> <li>CHANGELOG entry, alongside the alpha8 line that recorded the move to level 3.</li> <li>Green on both the current and the next-major lanes.</li> </ul> <h3>User interface changes</h3> <p>None on the vault itself. The two developer console forms in pdv_consumer_console start working instead of raising a TypeError.</p> <h3>API changes</h3> <p>None.</p> <h3>Data model changes</h3> <p>None.</p> <h3>Release notes snippet</h3> <p>Static analysis now runs at PHPStan level 5, up from level 3, still with no baseline and with no new ignore patterns. The consumer console request and store forms no longer raise a TypeError when built.</p> <p>AI-Generated: Yes (Claude Code was used to help draft this issue summary and to run the PHPStan measurements it reports. I reviewed them before posting; there is no code on this issue yet.)</p>