fix: infinite /partial request loop triggered by search input

[marekdano]

🐛 Bug-fix PR

Closes #3861

📌 Summary

Fix infinite loop of /partial endpoint requests triggered when typing in admin UI search bars (servers, tools, resources, gateways, prompts, agents).
Remove unnecessary search input re-initialization from htmx:afterSwap and htmx:afterSettle handlers, since search inputs live outside the swapped table DOM and persist across partial refreshes.

Fix npm high vulnerabilities

🔁 Reproduction Steps

1. Go to http://localhost:8080/
2. Select one the pages e.g. MCP servers
3. Open the browser console and search for server
4. Observe that calling /partial endpoint is called infinitely until the search is cleared

Root Cause

initializeSearchInputs() attached the input event listener before setting .value from URL state, so the value assignment immediately fired the listener, queuing a /partial reload whose swap re-initialized inputs — creating an infinite cycle

💡 Fix Description

Changes

1. Reorder value assignment and listener attachment in initializeSearchInputs() — set .value before adding the input listener so initialization doesn't trigger a reload
2. Remove search input re-initialization from htmx:afterSwap — search inputs are not part of the swapped table content; only update filter status
3. Remove search input re-initialization from htmx:afterSettle — same reasoning; only update filter status
4. Remove eager reload on init — the visible-panel check was queueing an immediate loadSearchablePanel call, but the server already returns correctly filtered data in the initial page load
5. Add regression tests (tests/js/admin-search-init-loop.test.js, 7 tests) covering:
   - Value restoration from URL state does not fire the input listener
   - No htmx.ajax call is made during initialization
   - User typing still triggers a debounced /partial reload (positive test)
   - htmx:afterSwap / htmx:afterSettle on table targets do not re-trigger search initialization
   - Search input value and listener survive table content swaps
6. run npm audit fix to fix high vulnerabilities

🧪 Verification

Check	Command	Status
Lint suite	make lint	✅
Unit tests	make test	✅
Coverage ≥ 80 %	make coverage	✅
Manual regression no longer fails	steps / screenshots

📐 MCP Compliance (if relevant)

• Matches current MCP spec
• No breaking change to MCP clients

✅ Checklist

• Code formatted (make black isort pre-commit)
• No secrets/credentials committed

[gcgoncalves]

Tested and working fine! :)

[vishu-bh]

LGTM 🚀

The fix looks correct, the regression coverage is targeted

[gcgoncalves]

Tested and works fine. The code is correct and the proper tests were added.

[gcgoncalves]

Have you considered using the createMemoizedInit function? I created it for a similar init loop, and the goal back then was to apply it to all inits, to prevent exactly this loop issue.

[marekdano]

@gcgoncalves
The code is already using createMemoizedInit correctly.

It already implements the createMemoizedInit pattern at line 19009 in admin.js:

const {
    init: initializeSearchInputsMemoized,
    debouncedInit: initializeSearchInputsDebounced,
    reset: resetSearchInputsState,
} = createMemoizedInit(initializeSearchInputs, 300, "SearchInputs");

The fix works by:

• Keeping the memoized initialization (already there)
• Removing the problematic resetSearchInputsState() + initializeSearchInputsDebounced() calls from HTMX event handlers
• Only calling updateFilterStatus() on swaps instead of re-initializing

The key change in the diff shows:

BEFORE (caused infinite loop):

document.body.addEventListener("htmx:afterSwap", function (event) {
    resetSearchInputsState();  // ❌ This bypassed memoization guards
    initializeSearchInputsDebounced();  // ❌ Triggered reload → swap → repeat
});

AFTER (fixed):

document.body.addEventListener("htmx:afterSwap", function (event) {
    updateFilterStatus();  // ✅ Only updates UI, no re-init
});

No changes needed - the implementation already follows the suggested pattern.