Repository navigation
BUG: Deleting a repo, while being added needs a dedicated algo #13
Description
The code should first check if the code to be deleted is currently being added. If yes, then it should first kill the job and then delete the package/code.
Activity
Shashankss1205 commentedon Aug 20, 2025
Even without the explicit cancel_job mechanism proposed, the indexing process for any package stops as soon as we initiate the deletion.
Here's why that happens:
mechanisms. When the add_package_to_graph (which calls build_graph_from_path_async) is running, it's
continuously performing write operations (MERGE statements) to create nodes and relationships for each file and
its contents.
DETACH DELETE's Power: When you call delete_repository_from_graph, it executes a powerful Cypher query (MATCH(r:Repository {path: $path}) OPTIONAL MATCH (r)-[:CONTAINS*]->(e) DETACH DELETE r, e). This query attempts to:
imports, calls, etc.) to any depth.
DETACH DELETE: This is the key. It first removes all relationships connected to the nodes being deleted,and then deletes the nodes themselves. This is a very aggressive and efficient way to remove an entire
subgraph.
any ongoing MERGE operations from the indexing job that try to write to those same nodes or relationships will
immediately fail. The target nodes either no longer exist or are locked for deletion.
build_graph_from_path_async: The build_graph_from_path_async function has try...exceptblocks. When a session.run() call (which is part of add_file_to_graph) fails due to the deletion, an exception
is raised. This exception is caught, and the indexing job's status is updated to FAILED.
In essence, the deletion didn't "cancel" the job gracefully; it effectively "pulled the rug out" from under the
indexing process. The indexing job stopped because its attempts to write to the database were met with errors due
to the concurrent deletion.
Why the
cancel_jobis still beneficial (even if it seems to work now):While the current behavior stops the indexing, it's an ungraceful termination.
transaction or a series of related writes, an abrupt failure could leave the database in a partially updated or
inconsistent state.
request, finish any current atomic operation (like processing a single file), and then gracefully exit, marking
its job as CANCELLED rather than FAILED. This leads to a cleaner state and more predictable behavior.
So, this observation is correct that it stops, but the proposed cancel_job aims for a more controlled and robust
shutdown, minimizing potential data integrity issues.
sreeja-code-dev commentedon Sep 29, 2025
Hi @Shashanks1205 👋,
I'd love to work on this issue as part of my Hacktoberfest contributions! The bug and its implications are super interesting, and I’ve already started exploring the 'build_graph_from_path_async' function and how the cancel_job mechanism could be improved for graceful termination.
Could you please assign this issue to me? Also, if possible, kindly add the 'Hacktoberfest' label so it counts toward my contribution.
Looking forward to collaborating—thanks for opening such a thoughtful issue!
Best,
Sreeja
Shashankss1205 commentedon Sep 29, 2025
Yes assigned. Good luck 🤞 any sort of confusions can be asked for either here or in the discord server (link in readme)
sreeja-code-dev commentedon Sep 29, 2025
For any confusions ,I will reach out. Thanks for assigning me this issue.
fix(deps): pin tree-sitter-language-pack <1.21.0 (1.21.0 drops all Ha…