Repository navigation
appmap.yml packages path matching zero classes yields a healthy-looking recording with no warning #332
Description
Summary
An appmap.yml whose packages: paths match zero classes produces a recording that looks healthy (HTTP route, status, SQL all present) with no warning. Not one line of application code is captured. With no appmap.yml the agent auto-detects the package and the recording is complete, so a wrong config is strictly worse than no config.
Agent 1.30.1, CLI 3.203.0, spring-petclinic @ b26f235, Java 17.
Repro
# appmap.yml (real package is ...petclinic.owner; one-character typo)
packages:
- path: org.springframework.samples.petclinic.ownersmvn -Dtest=PetClinicIntegrationTests#testOwnerDetails test
appmap query endpoints --appmap-dir tmp/appmap
appmap query find queries --appmap-dir tmp/appmap --limit 3Observed
No warning from agent or CLI. endpoints shows GET /owners/{ownerId} 200, find queries shows the eight expected SQL statements. The only tell is the file size (3.2 KB vs 8.6 KB with the right config) and an empty appmap query hotspots.
Cause
packages: governs only bytecode instrumentation of application classes; HTTP and JDBC events come from framework hooks that do not consult it. "Zero classes matched" is not treated as an error or warning, and the configured path is never validated against the classpath.
Expected
At the end of a recording the agent knows how many classes each path: entry instrumented. A path: matching zero classes should warn on stderr naming the entry; a config where every entry matched zero classes should be a hard error, not a silent 3 KB recording.
Activity
dividedmind commentedon Oct 8, 2026
I disagree. A config file could have many tightly targeted entries that match only in a few cases. When those entries don't match, this will be pure noise.
I don't think this should be a hard error — what if the user wants just the HTTP and SQL? This can be useful too. But I agree that showing a warning in this case would be useful.