Describe the bug
get_config_keys() returns a dict keyed by PyConfigKey.id, a can:// URI, on the Python backends (cldk/analysis/python/codeanalyzer/codeanalyzer.py:1672 and the Neo4j twin) and on TypeScript. The generic contract documents that as the key: cldk/analysis/commons/backend.py:163 says "keyed by its id".
Two consequences:
- The key is not stable across backends. The id embeds the application name, which the SDK stamps from the project directory's name when it runs the analyzer, while a graph carries whatever
--app-name the operator passed at emit time. So the in-process and Neo4j backends can return the same 336 config keys under entirely disjoint key sets. Java hit exactly this: 336 keys each, zero shared, and the parity test only passed because the reference graph happened to be emitted with a matching name.
- It puts a
can:// URI in a public return value, which the 2.0 surface rules exclude everywhere except ref, node_id and next_cursor.
Java now keys by the artifact-relative key instead (pom.xml@key/project.artifactId), with the id still on the model. Python and TypeScript still key by id, so the three languages disagree.
To Reproduce
Not stated in the original issue.
Expected behavior
Additional context
Scope boundary
In scope: the key of the dict get_config_keys() returns on Python and TypeScript, the generic ABC's docstring, and get_config_readers/get_config_uses where they look up by that key. Out of scope: PyConfigKey.id itself, which stays as the model's identity.
Caveats and known risks
- This is a breaking change to a return value's keys on two languages. It belongs in the 2.0 line with a CHANGELOG entry and a one-line migration, not in a patch release.
- Check whether any accessor round-trips the key back into an id before changing it.
Goals
Describe the bug
get_config_keys()returns a dict keyed byPyConfigKey.id, acan://URI, on the Python backends (cldk/analysis/python/codeanalyzer/codeanalyzer.py:1672and the Neo4j twin) and on TypeScript. The generic contract documents that as the key:cldk/analysis/commons/backend.py:163says "keyed by its id".Two consequences:
--app-namethe operator passed at emit time. So the in-process and Neo4j backends can return the same 336 config keys under entirely disjoint key sets. Java hit exactly this: 336 keys each, zero shared, and the parity test only passed because the reference graph happened to be emitted with a matching name.can://URI in a public return value, which the 2.0 surface rules exclude everywhere exceptref,node_idandnext_cursor.Java now keys by the artifact-relative key instead (
pom.xml@key/project.artifactId), with the id still on the model. Python and TypeScript still key by id, so the three languages disagree.To Reproduce
Not stated in the original issue.
Expected behavior
Additional context
Scope boundary
In scope: the key of the dict
get_config_keys()returns on Python and TypeScript, the generic ABC's docstring, andget_config_readers/get_config_useswhere they look up by that key. Out of scope:PyConfigKey.iditself, which stays as the model's identity.Caveats and known risks
Goals
can://URI appears in a public return value outside the sanctioned fields