sdk/basyx/aas/backend/local_file.py: Fix `discard()` in `LocalFileObjectStore`

[moritzsommer]

Current Situation

The _object_cache of the LocalFileObjectStore is not initialised when a new instance of the class is created. This means that the Identifiables from the local .json files are not loaded initially:

basyx-python-sdk/sdk/basyx/aas/backend/local_file.py

Lines 34 to 49 in e622edc

	def __init__(self, directory_path: str):
	"""
	Initializer of class LocalFileObjectStore
	:param directory_path: Path to the local file backend (the path where you want to store your AAS JSON files)
	"""
	self.directory_path: str = directory_path.rstrip("/")
	# A dictionary of weak references to local replications of stored objects. Objects are kept in this cache as
	# long as there is any other reference in the Python application to them. We use this to make sure that only one
	# local replication of each object is kept in the application and retrieving an object from the store always
	# returns the **same** (not only equal) object. Still, objects are forgotten, when they are not referenced
	# anywhere else to save memory.
	self._object_cache: weakref.WeakValueDictionary[model.Identifier, model.Identifiable] \
	= weakref.WeakValueDictionary()
	self._object_cache_lock = threading.Lock()

The cache is designed to operate efficiently, i.e. it is only filled with a specific Identifiable from a local .json file when the user searches for or adds it. Consequently, calling discard() on a newly initialised LocalFileObjectStore raises a KeyError whenever the Identifiable to delete exists in a local .json file, but is not present in the initially empty cache:

basyx-python-sdk/sdk/basyx/aas/backend/local_file.py

Lines 112 to 125 in e622edc

	def discard(self, x: model.Identifiable) -> None:
	"""
	Delete an :class:`~basyx.aas.model.base.Identifiable` AAS object from the local file store
	:param x: The object to be deleted
	:raises KeyError: If the object does not exist in the database
	"""
	logger.debug("Deleting object %s from Local File Store database ...", repr(x))
	try:
	os.remove("{}/{}.json".format(self.directory_path, self._transform_id(x.id)))
	except FileNotFoundError as e:
	raise KeyError("No AAS object with id {} exists in local file database".format(x.id)) from e
	with self._object_cache_lock:
	del self._object_cache[x.id]

Proposed Change

Ensure that the discard() method can handle an empty _object_cache by catching potential KeyErrors.

[s-heppner]

Reminder: Remove the quick temporary fix in AbstractObjectStore.sync after fixing this properly.

[AlwaysTwilight]

Agent run 54ce26dd46d64554b9d30c00e0528153 started.

[AlwaysTwilight]

Agent run 54ce26dd46d64554b9d30c00e0528153 failed: Command '['docker', 'run', '--rm', '--cpus', '1.0', '--memory', '2g', '-v', 'D:\SWE_Agents\.work\54ce26dd46d64554b9d30c00e0528153\repo:/work', '-w', '/work', 'python:3.11-slim', 'sh', '-lc', 'if ! command -v git >/dev/null 2>&1; then apt-get update -y >/dev/null 2>&1 && apt-get install -y git >/dev/null 2>&1; fi; git diff --numstat']' timed out after 30 seconds

[AlwaysTwilight]

Agent run dca4d6d2008048378ca95c186e464b79 started.

[AlwaysTwilight]

Agent run dca4d6d2008048378ca95c186e464b79 failed: Command '['docker', 'run', '--rm', '--cpus', '1.0', '--memory', '2g', '-v', 'D:\SWE_Agents\.work\dca4d6d2008048378ca95c186e464b79\repo:/work', '-w', '/work', 'python:3.11-slim', 'sh', '-lc', 'if ! command -v git >/dev/null 2>&1; then apt-get update -y >/dev/null 2>&1 && apt-get install -y git >/dev/null 2>&1; fi; git diff --numstat']' timed out after 30 seconds

[moritzsommer]

Okay, this is kind of scary. An AI coding agent has gone rogue and is crawling its way through GitHub, posting all status messages in this issue thread. Apparently, I triggered it via the GitHub API when I edited the issue text. Is this common? What should we do? 😅

[s-heppner]

Fun. I suspect this is someone's personal agent (possibly openclaw.ai), considering the path's its running from is a local Windows machine (D:\SWE_Agents\...).
If this is the only time this happens, I think we'll ignore it, otherwise we report the GitHub user as spamming and block it from writing issues to our project.
I'm afraid there's no way of figuring out whoever let this agent loose on our repo, I've skimmed openclaw's documentation, there’s no apparent official way to report “misbehaving OpenClaw bots” anywhere.

[AlwaysTwilight]

guys chill i was just testing something from my local system nothing scary is going on 😂😅.

[s-heppner]

Thanks for the clarification.

For future reference, please don’t run experiments that post automated output into open source project issues.
It creates noise and makes it harder to track real discussions.

If you’d like to experiment with the project, feel free to fork it or open a draft PR instead.

[moritzsommer]

While fixing this issue, I noticed that the _object_cache is always updated but never used as an actual lookup cache. None of the operations of the LocalFileIdentifiableStore require the cache, it just runs alongside:

basyx-python-sdk/sdk/basyx/aas/backend/local_file.py

Lines 64 to 85 in e622edc

	def get_identifiable_by_hash(self, hash_: str) -> model.Identifiable:
	"""
	Retrieve an AAS object from the local file by its identifier hash
	:raises KeyError: If the respective file could not be found
	"""
	# Try to get the correct file
	try:
	with open("{}/{}.json".format(self.directory_path, hash_), "r") as file:
	data = json.load(file, cls=json_deserialization.AASFromJsonDecoder)
	obj = data["data"]
	except FileNotFoundError as e:
	raise KeyError("No Identifiable with hash {} found in local file database".format(hash_)) from e
	# If we still have a local replication of that object (since it is referenced from anywhere else), update that
	# replication and return it.
	with self._object_cache_lock:
	if obj.id in self._object_cache:
	old_obj = self._object_cache[obj.id]
	old_obj.update_from(obj)
	return old_obj
	self._object_cache[obj.id] = obj
	return obj

Or is the cache actually intended to work as an identity map, so that one .json file is represented by exactly one and only one canonical in-memory instance? In this case, I just got confused by the naming.

Another issue we should address is that we write to _object_cache outside the lock.