[pull] main from danny-avila:main - #575
Merged
Merged
Conversation
* 🙋 fix: Free the Composer When a Question Pause Collapses Collapsing a live `ask_user_question` left the user with nothing to do. A batch of questions disables the composer, the send button, and the stop button for as long as the pause is active — and `collapse` deliberately keeps it active, while hiding the popover that carried the only dismiss. After the chevron there was no way to type, send, or stop the run short of reloading the page. Split the composer's role out of `active`: `composerAnswers` (a single question, answered IN the composer) and `composerLocked` (a batch, answered in its own card — and only while the popover is up). Collapsing a batch now hands the composer back to the thread; the stop button follows `composerAnswers`, so a paused run stays stoppable. Both collapsed cards also carry the popover's ×, so dismiss survives the handover, and `submitText` declines a batch's composer text instead of claiming it — the old `return true` reported success and dropped whatever was staged when the pause began. Contrast, per feedback that the questions were hard to read: the answer options, the answer textarea, and the digit chips all drew their edge from `border-light`, which measures 1.20:1 against the panel (WCAG 1.4.11 wants 3:1 for a UI component boundary) — a column of choices read as flat text. Adds a `choice` Button variant carrying its own fill and a `border-xheavy` edge (5.49:1 dark / 6.54:1 light), at `font-normal` so the question above stays the heading, and replaces the single-question popover's hardcoded `bg-white`/`dark:bg-gray-700` with the semantic surface role it should have been using. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UPtmUb6VLBhhxXkS3PfV6r * 🧹 refactor: Render Popover Answers Through the Choice Variant The popover's option rows re-stated the shared `choice` variant's border, fill, weight, and hover on a raw `<button>` — the same answer control as the cards', so a later fix to the variant would have drifted the live popover away from them. Renders `Button variant="choice"` instead, keeping only what the popover actually owns: the full-width row layout and the keyboard highlight. Locked rows now take the primitive's `disabled:` styling rather than a local `cursor-not-allowed opacity-60`, matching the cards. -----
…cation (#15010) The MCP tool-call catch block classifies errors by message substring, so an OpenIDReauthRequiredError raised during header resolution was rewritten into an MCP OAuth configuration prompt and its class identity discarded. The typed error now passes through ahead of the heuristic, so the actionable re-authentication message reaches the caller intact.
The "auto scroll to latest message" setting stopped taking readers to the newest message when opening a conversation, most visibly on long threads. `useMessageScrolling` fired its landing on the conversation id alone. That id reaches the hook a commit or more before the tree does, so `scrollIntoView` ran against the OUTGOING conversation's rows: it scrolled that thread to its end, and — having no dependency on the tree — never ran again once the requested thread mounted. The reader was left at whatever offset the old thread's bottom happened to be, which on a long thread is the top. Key the landing on the conversation that owns the RENDERED rows instead, using the same `messagesTree[0].conversationId` fallback `MessagesView` already uses to key the mount window, and land once per conversation so the tree identities a stream mints cannot haul back a reader who scrolled away. This is independent of the progressive row mounting: that window only ever grows upward from the newest row, so the end of the mounted content is already the end of the thread, and the landing needs no full mount to be correct. Measured against the real client (react-scan render tallies over a 10-message to 120-message navigation), render counts are unchanged at ~16k and the thread still mounts progressively; distance from the bottom on arrival goes 841px to 0. With progressive mounting disabled the same navigation landed 15421px from the bottom, confirming the anchoring was masking this rather than causing it. Also moves the `autoScroll` setting from Recoil to Jotai, keeping the same `autoScroll` localStorage key so a stored preference survives, and matching the `showThinking`/`smoothStreaming` atoms already served through `ToggleSwitch`. Claude-Session: https://claude.ai/code/session_01BDQSLdbwvtSqCmQSw7Nz91 Co-authored-by: Claude <noreply@anthropic.com>
* 🖼️ fix: Keep Composer Send Enabled When an Attachment Stalls The composer's send button is gated on `hasIncompleteFiles(files)`, so any attachment that can never reach `progress: 1` reads as "still uploading" and disables send for the rest of the session — draft text intact, no error, no way out but removing the chip or reloading. Two paths could park an attachment there: - `loadImage` starts the upload from `img.onload` and had no `onerror`, so an image the browser refuses to decode (unsupported codec, truncated bytes, a revoked object URL) never uploaded at all and stranded the file at `progress: 0.2`. Drop the file and surface the error instead. - Upload completion reconciled against `temp_file_id`, the server's echo of the id the request was sent with, while every client-side handle for that upload — file map key, delayed-toast timer, recovery callbacks — is keyed by the id the client owns. A mismatch applied the completion update to a key that does not exist, leaving the attachment at `progress: 0.9`. Covered by unit regressions in the file-handling suite and a composer-level spec that drives a real upload through `ChatForm`, plus a render-bound guard on typing (react-scan measures one ChatForm render per keystroke in a browser; the guard fails on a multiplier). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cq3tev2rPbc2pWyVJwnh6u * 🧹 fix: Stop the Draft Restore From Clobbering Live Composer Attachments `restoreFiles` runs on every `QueryKeys.files` write — an upload landing, an SSE attachment mid-run — not just on a conversation swap, and it was written as if the draft were always the whole truth: - An empty draft cleared the composer outright. On the swap path that is redundant (the effect already clears explicitly one line earlier); on the cache path an empty draft only means the draft write has not caught up, so clearing there discards an attachment the user just added — and with no text typed, the send button has nothing left to submit. Restoring now only adds. - A match replaced the composer's entry with the persisted record, dropping the local `File`, the blob preview the chip renders from (`FileRow` falls back to refetching `filepath`), and the tool resource the upload was staged under, and stamping `attached: true` so removing a chip the composer still owns leaves the file orphaned server-side. It now layers the record over the live entry and leaves `attached` to files actually adopted from a draft. Confirmed against a real browser run: the entry is at `progress: 0.9` when this restore fires, so it — not the upload's own completion — is what was re-enabling send. react-scan render counts are unchanged (typing 20 keystrokes: 111 renders, ChatForm=20; attaching an image: 1373, FileRow=6). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cq3tev2rPbc2pWyVJwnh6u * 🔗 fix: Keep an Attachment's Stored Temporary Id Equal to Its Map Key Two follow-ups from review on the upload reconciliation. Completion stored the server's `temp_file_id` echo in the entry's value while keying the map by the id the request was sent with. `useFileDeletion` deletes map entries by the value's own `file_id` and `temp_file_id`, so where the two disagreed — the exact case the reconciliation exists to tolerate — Remove would delete the file server-side and leave the chip behind, and the draft restore could not correlate its saved key with the cached record. Store the request id. A refused image decode also left its `uploadScope.recent` reservation behind: reservations are released by the render that observes the file in the shared state, which a decode failing before that render never reaches, and once the file is deleted no later render can either. The ghost is merged into every later batch's validation, so re-picking the same file reads as a duplicate and its size keeps counting against the composer's limits. Both covered; both new guards fail without their fix. Also sorts the composer spec's imports, which the static-checks import-order gate flagged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cq3tev2rPbc2pWyVJwnh6u * 🧷 fix: Normalize an Upload's Temporary Id at the Cache Boundary The composer keys its file map — and the draft it saves — by the `file_id` the upload request was sent with; `temp_file_id` is only the server's echo of that id. The previous commit reconciled the composer's own entry against the request id but left the record the mutation inserts into `QueryKeys.files` carrying the raw echo, and `restoreFiles` can only correlate a saved draft id by matching a cached record's `file_id` or `temp_file_id`. Where the echo disagreed the draft matched neither, so the attachment was silently dropped on the next conversation switch or reload — the same class of loss, one layer further out. Normalize once where the response enters client state, and hand the normalized record to the mutation's callers, so the cache, the composer entry and the draft all agree on one id. An agreeing response is passed through untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Cq3tev2rPbc2pWyVJwnh6u --------- Co-authored-by: Claude <noreply@anthropic.com>
* fix: preserve detached subagent owner context * style: sort detached subagent imports
…eam Fixes (#15012) * chore: bump `librechat/agents` to v3.6.7 * v3.6.8
* refactor: presets, skills motion and model selector polish Four surfaces that had drifted from the rest of the app, plus the CI fragility that surfaced while getting them green. Two were functional bugs rather than styling: Keyboard focus was invisible in the model selector. The highlight rule existed and the background was painted, but it used surface-secondary and the menu sits on bg-presentation, which resolve to the same value in dark and to within 3/255 in light, so only the thin indicator bar ever showed. Keyboard focus now uses the same surface a pointer gets. Importing a malformed preset raised com_ui_upload_invalid, which talks about image size limits, and FileUpload's JSON.parse had nothing catching it at that call site. The overflow menu owns the input and reports the existing preset import error instead. The rest is polish: preset surfaces use the theme radius roles rather than raw values; the edit dialog stops nesting a fixed 350px scroll box inside an already scrolling dialog and pins its title and actions, with the endpoint picker moved to ControlCombobox and kept out of any clipping ancestor; Clear all and Import move into a three-dots menu matching the conversation row; the Skills sections and pinned chats adopt the Collapse that Projects already used; the rendered/source toggle slides between states, is extracted rather than duplicated, and gains the accessible name and RTL mirroring it lacked; the header toggle loses its fill and the mobile new chat button hides when you are already in a new chat. The CI changes are unrelated to the UI but blocked it: the MCP and Redis cache jobs installed Redis with a bare apt-get and lost a race against the runner's own apt-daily work, failing four times and once hanging for 30 minutes. They now stop that background work and wait for the lock. DPkg::Lock::Timeout alone does not help, since it covers the dpkg frontend lock and not the lists lock. * refactor: move the section label appearance into the Label primitive The preset dialog reached into the agent panel's private `Advanced/ui` for its field eyebrow, so an agent-only refactor could change the dialog. Give the shared `Label` a `section` variant and export the recipe for the agent id row, which heads its value on a span and must not inherit the label's block layout. Each variant carries its own size, leading and color: the recipe output reaches that span unmerged, and a font size declared after `leading-none` drops it. * fix: derive the mobile new chat action from the route The context conversation still holds the previous chat for a render after a history or link navigation, a lag ChatView already guards against, so the action could show on /c/new or hide while an existing chat loaded. * style: sort imports in the touched files * fix: return focus to the menu item after the clear dialog The dialog is controlled and has no trigger, so Radix restored focus to whatever held it when the content mounted, the menu's own focus trap, and a keyboard user was left on the document. The menu stays open behind the dialog, so the invoking item is still there to take focus back. * fix: fall back to the trigger when clearing removes the invoking item Confirming empties the presets optimistically, so React commits the removed menu item together with the dialog close and the saved invoker is already disconnected when focus is handed back. --------- Co-authored-by: Danny Avila <danny@librechat.ai>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )