Detect loaded dependencies at runtime

[hansott]

No uber jar support yet!

[codecov]

Codecov Report

❌ Patch coverage is 69.23077% with 44 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
.../agent_api/helpers/packages/JarPackageScanner.java	74.72%	12 Missing and 11 partials ⚠️
..._api/helpers/packages/RuntimePackageCollector.java	67.64%	6 Missing and 5 partials ⚠️
...aikido/agent_api/storage/RuntimePackagesStore.java	46.15%	7 Missing ⚠️
...dev/aikido/agent_api/background/HeartbeatTask.java	0.00%	3 Missing ⚠️

📢 Thoughts on this report? Let us know!

[Mishenevd]

If we clean packages every heartbeat, jar is only reported in the heartbeat where its first class loads, after that it stays loaded but never gets reported again

By default ui only shows deps seen in the last 24h

If application runs for more than a day, all reported dependencies will disappear from the dashboard. I think that's misleading

[aikido-pr-checks]

🟡 Medium - Heartbeat drops the dependency inventory after the first report

RuntimePackagesStore is cleared on every heartbeat, but RuntimePackageCollector only ever enqueues a JAR location the first time it is seen because OBSERVED_LOCATIONS is never reset. That means already-loaded libraries disappear from all later heartbeats, and even a transient failure on the first report permanently loses the inventory because those locations will not be scanned again. The backend will therefore miss still-loaded dependencies and any vulnerability analysis built on this heartbeat data becomes incomplete.

Show fix

Do not treat loaded dependencies as per-heartbeat deltas. Keep RuntimePackagesStore persistent across heartbeats, or rebuild it from the full set of loaded classes before clearing anything; if you need delta reporting, only delete entries after a successful report and also make the collector able to repopulate them.

_{More info - Reply on this comment to give feedback or ignore the issue.}