calculated version mistakenly memoized across builds

[devhawk]

workaround, --stop or --no-daemons with gradlew

[devhawk]

Closing as not reproducible. Notes for anyone who lands here from a similar symptom.

The suspect path is unchanged since this was filed. AppVersionComputer.computeAppVersion on 2026-07-01 is byte-for-byte identical to today in the part that matters; only app-name hashing was added since (#471). So this wasn't silently fixed, and the failure to reproduce isn't because the code moved.

No memoization exists in DBOS. The version is computed once per launch in DBOSExecutor.start and cached only on the executor instance. Nothing persists across processes. The only line in the path that reaches outside the process is the class-file read:

var cl = klass.getClassLoader();
try (var in = cl.getResourceAsStream(klassPath)) { ... }

Could not reproduce. A scratch Gradle project hashing its own .class through getResourceAsStream, edited between builds with the daemon alive, produced a different hash every time under both run and test. Expected — a directory classpath entry stats the file on each call.

The likely explanation is expected behavior. The hash covers only the workflow method's own bytecode, plus its fully-qualified name and descriptor. Editing a step, a helper, or anything the workflow calls leaves the version byte-identical. Python scopes it the same way (inspect.getsource(wf) over registered workflows only), so this is deliberate and consistent, not a Java bug. Change code, rebuild, version doesn't move, reach for --stop, next edit happens to touch the workflow body, version moves — that fits every observation here including the workaround, with no bug involved.

One real but unconfirmed hazard, for the record. URLClassPath.JarLoader holds an open JarFile for the life of a classloader, and the Gradle daemon caches classloaders across builds. If workflow classes ship in a jar that is rebuilt underneath a cached loader, stale bytes are possible, and --stop would clear it. That is a genuine hazard for jar-packaged workflows; there is just no evidence it is what happened here.

Hardening that would close that hazard, if anyone wants it as its own issue: resolve klass.getProtectionDomain().getCodeSource().getLocation() and read the entry directly from the directory or a freshly-opened JarFile, keeping getResourceAsStream as a fallback. It would also fix duplicate classpath entries shadowing each other (a stale editor-generated bin/ alongside build/classes/ — this repo produces both), where getResourceAsStream can return an entry other than the one actually loaded.