Skip to content

fix(router): remove persisted route_config key on SemanticRouter.delete()#635

Open
vishal-bala wants to merge 1 commit into
mainfrom
fix/semantic-router-delete-config-key
Open

fix(router): remove persisted route_config key on SemanticRouter.delete()#635
vishal-bala wants to merge 1 commit into
mainfrom
fix/semantic-router-delete-config-key

Conversation

@vishal-bala

@vishal-bala vishal-bala commented Jun 23, 2026

Copy link
Copy Markdown
Collaborator

Motivation

A SemanticRouter persists its configuration as a standalone JSON key, {name}:route_config, written when the router is constructed and rewritten on every route change. delete(), however, only drops the router's search index — it never removes that key. The index is built over hash documents, and FT.DROPINDEX ... DD deletes only the documents the index actually tracks, so the JSON config key falls outside its reach and survives every call to delete().

The immediate consequence is orphaned :route_config keys accumulating in Redis. The subtler one is a correctness gap: from_existing() loads a router straight from that key, so a router that was supposedly deleted can be silently resurrected from stale config. It also leaves residue behind in the test suite, where it contributed to the broader Redis-backed isolation problems tracked in #546.

Fix

delete() now removes {name}:route_config explicitly after dropping the index, so deleting a router fully clears its state. The change is confined to SemanticRouter.delete(); there is no async router variant to mirror.

A regression test constructs a router, confirms the config key exists, calls delete(), and then asserts both that the key is gone and that from_existing() on the same name raises rather than reloading stale config — locking in the behaviour described above.

Closes #634.


Note

Low Risk
Small lifecycle fix in router teardown with a focused regression test; no changes to routing, auth, or data semantics beyond complete cleanup on delete.

Overview
SemanticRouter.delete() now drops the search index and explicitly deletes the standalone Redis JSON key {name}:route_config, which is not removed by FT.DROPINDEX because it sits outside the index.

This prevents orphaned config keys and stops from_existing() from reloading a router that was supposed to be deleted.

An integration test asserts the config key is gone after delete() and that from_existing() raises when no valid config remains.

Reviewed by Cursor Bugbot for commit 23805cf. Bugbot is set up for automated code reviews on this repo. Configure here.

@jit-ci

jit-ci Bot commented Jun 23, 2026

Copy link
Copy Markdown

🛡️ Jit Security Scan Results

CRITICAL HIGH MEDIUM

✅ No security findings were detected in this PR


Security scan by Jit

SemanticRouter.delete() dropped the search index but left the standalone
{name}:route_config JSON key in Redis, since that key is not tracked by
the index. Delete it explicitly so deletion fully removes router state.

Closes #634

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@vishal-bala vishal-bala force-pushed the fix/semantic-router-delete-config-key branch from 24b0fbb to 23805cf Compare June 23, 2026 13:06
@vishal-bala vishal-bala marked this pull request as ready for review June 24, 2026 08:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SemanticRouter.delete() leaves orphaned {name}:route_config key in Redis

1 participant