Inventory Management analysis assertion has been failing since at least July 28, hidden by continue-on-error

[fabianvf]

partially-migrated-apps-scenario.test.ts:434 has been failing on every infrastructure run since at least July 28. Nobody has noticed because the check still reports green.

The failure

1) [solution-server-tests] › e2e/tests/solution-server/partially-migrated-apps-scenario.test.ts:434:9
   Error: Analysis validation failed for Inventory Management: expect(received).toBe(expected)
   Expected: 2
   Received: 3

validateAnalysisResults counts .pf-v6-c-card__header-toggle elements and asserts toBe(2). It gets 3.

Seen on:

• 🐛 Validate custom rules file types in profile file dialog #1477, 2026-07-28, job
• 🌱 unbreak vscode-test on VS Code 1.131.0 and the changelog check #1480, 2026-08-04, job
• 🐛 match hub label selector semantics for synced profiles #1478, 2026-08-04, job

Three unrelated PRs, same assertion, same numbers, so this is deterministic rather than flaky. I have not gone back further than July 28 to find the first bad run.

Why it is invisible

test-infrastructure is continue-on-error on PRs, added in #1436 while the extension's hub auth was being migrated. So the step exits 1 and the job still reports pass:

1 failed
4 did not run
2 passed (8.1m)
##[error]Process completed with exit code 1.

Note the 4 did not run. The failure aborts the rest of the batch, so four infrastructure tests have not executed on any PR for over a week. That is the part I would fix first, independent of the assertion. Right now a green Infrastructure Tests check does not mean the infrastructure tests passed.

Likely cause

The expectation is a hardcoded count, and collect-assets pulls the rulesets release unpinned at build time, so a new rules release can add a violation and silently invalidate it. Same shape as the VS Code 1.131.0 breakage in #1480, where nothing in the repo changed but CI started failing on its own.

I have not confirmed what the third violation is yet. Will add that once I have it.

Suggested fixes

• Work out whether 3 is correct. If it is, update the expectation, and prefer asserting on violation identity rather than a bare count so the next rules bump gives a useful error.
• Make the infrastructure job's result honest again, or at minimum stop a single failure from skipping the remaining tests.

[fabianvf]

Reproduced locally on macOS with freshly collected assets, same 3 violations as CI, so this is deterministic rather than environmental.

The three cards are:

violation	incidents
audit-logging-migration/audit-logging-0003	1
openjdk11/openjdk8/removed-javaee-modules-00020	2
openjdk7/oraclejdk7/oracle2openjdk-00006	1

The first two are the pair the test was written against. The third is new, and it looks like a false positive rather than a legitimately new finding.

oracle2openjdk-00006 fires on com.sun.image.codec.jpeg.*:

when:
  or:
    - java.referenced: { location: CONSTRUCTOR_CALL, pattern: com.sun.image.codec.jpeg.* }
    - java.referenced: { location: IMPORT, pattern: com.sun.image.codec.jpeg.* }
    ...

The incident it reports is InventoryService.java:36:

auditLogger = new FileSystemAuditLogger(config);

That is com.enterprise.audit.logging.service.FileSystemAuditLogger. The string com.sun.image.codec.jpeg does not appear anywhere in the repository. So a CONSTRUCTOR_CALL pattern for one package is matching a constructor from an unrelated one.

My guess is the custom com.enterprise.audit.logging jar is not resolvable on the analysis classpath, so the type does not resolve and the pattern match degrades into matching the constructor call regardless of package. Worth confirming with someone who knows the java provider better than I do.

Two consequences:

• Bumping the expectation from 2 to 3 would be wrong. It would bake a false positive into the test.
• If the pattern match really does degrade on unresolved types, that is not confined to this test. It would inflate results for any app with dependencies the provider cannot resolve.

The rule's labels are konveyor.io/target=openjdk7+ and konveyor.io/target=openjdk, which both legitimately match the profile's target=openjdk21 through version range semantics, so rule selection is not the problem here. The rule is correctly selected and then matches the wrong code.

Unrelated, but it bit me while reproducing: global.setup.ts builds its repo info as { repoUrl, repoName, language } and drops branch, so TEST_REPO_NAME=inventory_management clones main rather than the fixture's partial.