You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
get_config_keys() keys its dict by a can:// id on Python and TypeScript, which is unusable across backends and breaks the no-URI rule #346
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
The parity test passes with a deliberately mismatched application name
CHANGELOG records the key change per language with its migration
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
All three languages key config dicts the same way, and the ABC documents that key
No can:// URI appears in a public return value outside the sanctioned fields
A cross-backend test that would have caught the Java case: same project, backends attached from a graph emitted under a different application name, key sets equal
Activity