mirror of
https://github.com/nesquena/hermes-webui.git
synced 2026-07-17 05:01:23 +00:00
ai-ag2026
7707ea1d2a
Two independent defects that chain into "new conversations cannot be started": every POST /api/session/draft and /api/chat/start 404s a few seconds after POST /api/session/new returned 200. 1. Search inputs are parsed as username fields. index.html contains no <form> at all, but does contain password inputs (the Settings "Access Password" panel). Chromium therefore groups the document's unowned fields into one synthetic password form and picks the first text input in the DOM — #sessionSearch, the sidebar conversation filter — as that form's username field, then autofills the saved account name into it on load. autocomplete="off" was already present; it is ignored for credential heuristics. The autofill fires oninput -> filterSessions() -> GET /api/sessions/search ?content=1&depth=5: a full content search the user never asked for, repeated on every page load. Fix: give the four search inputs type="search" plus the per-manager opt-outs (data-1p-ignore / data-lpignore / data-bwignore / data-form-type), and give the Settings password inputs a real <form> owner with proper autocomplete tokens so Chromium scopes the credential form to them instead of to the whole document. The form uses display:contents, so layout is unchanged. CSS suppresses WebKit's native search clear button, since these fields ship their own (#sessionSearchClear). 2. A never-persisted session is treated as evictable. new_session() intentionally keeps a session in RAM until its first message (#1171), so the SESSIONS cache is its only copy. _session_is_evictable() (#4765) short-circuited on zero messages, reasoning that an empty shell "is recreated on next access". It is not: get_session() has no recreate path and raises KeyError, so both routes 404 and the session can never be started. The content search from (1) pulls every hit through get_session(), which blows past sessions_cache_max (default 300) and evicts the session being composed. That is why this reproduces within seconds on an install with ~1700 sessions, and why it grew worse as the session count rose. Fix: require proof of persistence before evicting, for empty sessions too — which is what the function's own docstring already promised ("Its full state is already persisted to the JSON sidecar"). The zero-message branch was the single path that bypassed it. #4765's memory bound is unaffected: sessions loaded from disk remain evictable, and its existing tests still pass. Trade-off: an unsaved empty session now stays resident for the process lifetime (one per "New Conversation" click, an empty object each). That is a deliberate application of the function's stated invariant — "slightly more RAM for a session we are unsure about is strictly better than evicting an unsaved session". Bounding it by age instead would also work if maintainers prefer. Validation: pytest tests/test_issue4765_sessions_lru_eviction.py -> 9 passed The added regression test fails on the unpatched predicate (verified by reverting api/models.py alone) and passes with the fix. Note: (1) fixes what triggers the churn, (2) fixes what turns that churn into an unstartable session. Either fix alone leaves a real defect in place, so they are submitted together. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>