Per-conversation tag writes already convert their conversation under
forced ephemeral retention, but global bookmark-tag renames and deletes
rewrite conversation rows via Conversation.updateMany without setting
isTemporary/expiredAt. A permanent chat tagged before the install
switched to ephemeral, touched only by a tag rename or delete, would
keep its retention fields unset and stay visible and non-expiring.
Add cascadeForcedRetentionByTag plus an applyForcedRetentionToTag method
that bulk-converts every conversation carrying a tag (and backfills its
messages and caps its shares) through the shared gap filter, so it never
extends a chat that already expires sooner. Load the interface config on
PUT /:tag and DELETE /:tag and route those writes through it.
A message-only forced save (branch/artifact/abort/edit) to a parent
carrying an active expiry sooner than the freshly computed ephemeral
window only capped when the parent was already temporary. An all-mode
parent (isTemporary: false) with an earlier active deadline skipped the
cap, so the touched message took the later window and the cascade then
rewrote the parent and its messages to that later date, extending data
that was meant to expire sooner.
Cap on any active parent expiredAt earlier than the forced window,
regardless of isTemporary, and feed the capped deadline into the
conversation cascade so it converts the parent without extending it.
Bookmark-tag writes update Conversation rows directly without saveConvo, so under
ephemeral retention adding a tag to a chat (createConversationTag) or changing a
chat's tag list (updateTagsForConversation) left an older permanent conversation
with isTemporary/expiredAt unset, keeping it visible and non-expiring.
Make applyForcedRetention's messageId optional so it can run the conversation
cascade alone, load app config on the per-conversation tag routes (POST /api/tags
when adding to a conversation, PUT /api/tags/convo/:conversationId), and enforce
retention after the write.
Forced ephemeral retention turns the TEMPORARY_CHAT permission on, which keeps the
global toggleTemporaryChat shortcut (Ctrl/Cmd+Shift+Y) registered even though the
badge is disabled. Pressing it flipped store.isTemporary off in an enforced chat,
so the next submission carried isTemporary false and the client queued title
generation and history entries while the server saved the chat as hidden
temporary.
Gate handleToggleTemporaryChat when retention is enforced so the shortcut is a
no-op, matching the disabled badge and keeping the enforced temporary state.
A SharedLink embeds a snapshot of the conversation (message refs and file
snapshots) and its TTL index keys off expiredAt alone, while shared-link reads
use activeExpirationFilter. So a permanent share (expiredAt null) created before
an install switched to ephemeral stayed publicly readable indefinitely after the
forced-temporary conversation and messages TTL out.
Add capConversationSharedLinks and call it wherever forced retention converts a
conversation - saveConvo's backfill, the shared cascade, and the cap-to-parent
path - so existing shares with no expiration or a later one are capped to the
forced deadline and expire with the conversation.
When a message-only forced save caps to a parent that is already temporary and
expires before the freshly computed window, the gated cascade leaves the parent
untouched (modifiedCount 0) and skips the message backfill. Older messages with
expiredAt null or a later deadline then survive after the parent's TTL deletes
the conversation.
Extract the cap logic into capForcedRetentionToParent, shared by saveMessage and
applyForcedRetention, which now also backfills the conversation's non-conforming
messages to the parent's earlier deadline. The hot normal-send path does not cap,
so it keeps the gated cascade with no extra per-message work.
Two more message-write paths bypassed ephemeral enforcement:
- The edit and feedback endpoints call updateMessage directly, without loading
retention config, so editing an older permanent message after a switch to
ephemeral left the message and its conversation non-temporary and visible.
Load config on those routes and run a new applyForcedRetention helper after the
update, which stamps the message and cascades the conversation/messages.
- The sendError and denyRequest middleware save messages with retention config
but never call saveConvo, so a validation/model error or denied-request message
could outlive its conversation. Pass capExpiryToConversation like the other
message-only paths.
Extract the conversation cascade into a shared cascadeForcedConversationRetention
helper used by both saveMessage and applyForcedRetention.
The agents /chat/abort endpoint and the resumable disconnect handler save a
partial response through saveMessage without saveConvo following, but did not
pass capExpiryToConversation. In an ephemeral deployment with a parent that
already has an earlier active expiredAt, the partial response got a freshly
computed later deadline and outlived its conversation.
Pass the same cap metadata used by the other message-only abort path so the
partial response cannot outlive its parent. If generation later completes, the
normal response-end save re-stamps the message with a fresh deadline.
Capping every forced message save to the parent expiry broke the normal send
paths: POST /api/messages/:conversationId and BaseClient.saveMessageToDatabase
call saveConvo right after saveMessage, refreshing the conversation to a fresh
TTL. The message kept the older parent deadline, so the message TTL index could
delete the just-sent message while the conversation stayed visible until the
later deadline.
Gate the cap behind a capExpiryToConversation flag that only the message-only
callers (branch, artifact, abort) set, since those never run saveConvo. Normal
sends leave the message on its fresh deadline, which the following saveConvo
refresh keeps aligned. The conversion/re-cap cascade still runs for every forced
save.
A message-only forced save (branch, artifact, abort) does not run saveConvo, so
on an existing ephemeral conversation whose expiredAt is already sooner than the
freshly computed window the parent was left untouched while the message received
the later deadline. The conversation could then be TTL-deleted first, leaving the
new or edited message orphaned until its later expiry.
Read the parent once before saving the message and cap the message deadline to an
already-temporary parent that expires sooner, so the message never outlives its
conversation. The same read gates the existing conversion/re-cap cascade, which
keeps extending or shortening the parent when that is the correct action.
The forced-retention cascade only matched parents that were not yet temporary,
so switching from a longer temporary TTL to a shorter ephemeral one skipped
conversations already marked isTemporary: true. Their older messages kept the
longer deadline and could outlive the forced ephemeral window.
Match parents and messages whose expiration is missing or later than the forced
deadline, even when already temporary, via a shared gap filter. The cascade
re-caps those documents and stays a no-op once they already expire within the
forced window.
The forced-retention cascade keyed conversion off expiredAt: null, so a switch
from all to ephemeral retention skipped conversations that were already
isTemporary: false with a future expiredAt. Message-only paths (branch, artifact,
abort) then produced a temporary message under a parent that stayed visible in
history via the active non-temporary branch of the visibility filter.
Gate the cascade on isTemporary !== true instead so saveMessage, saveConvo, and
the message backfill all convert non-temporary parents and their messages
regardless of an existing active expiration, while remaining a no-op once a
conversation is already temporary.
Enabling ephemeral retention on an installation with pre-existing permanent
chats only stamped a TTL on whichever document a route happened to save.
saveConvo gave the conversation an expiredAt while its existing messages kept
expiredAt: null, so the messages outlived the conversation under the message
TTL index. Conversely, message-only routes (branch, artifact edits) marked the
message temporary while leaving the parent conversation permanent and visible.
Cascade the chosen expiration across both documents on conversion: saveConvo
backfills the conversation's existing messages when it first converts a
permanent conversation, and saveMessage converts the parent conversation (and
backfills its messages) when forced retention applies to a message. Both are
gated to the one-time permanent-to-ephemeral transition to avoid per-save
overhead.
getSharedLinkExpiration starts a brand-new retention window when the source
conversation still has an active expiration, letting a share outlive the
conversation whose messages it embeds. Cap the share at the earlier of the
source expiration and a freshly created window, and fall back to the source
expiration when window creation fails.
The Assistants chat path saved messages via recordMessage, which bypasses
retention, while saveConvo forced the conversation temporary. In ephemeral
mode the conversation expired but its messages persisted with no expiredAt.
Route saveUserMessage, saveAssistantMessage and syncMessages through
saveMessage so messages inherit the same forced retention as the conversation.
The /archive and /update routes call saveConvo with req.config.interfaceConfig
but did not run configMiddleware, so req.config was undefined. After enabling
ephemeral retention, archiving or renaming a pre-existing permanent
conversation left it non-temporary with no expiredAt, bypassing the policy.
Apply configMiddleware to both routes so saves enforce retention consistently.
The messages routes (branch, artifact, post), share-link create/patch, and
the agent chat-abort route read req.config.interfaceConfig but never ran
configMiddleware, so req.config was undefined and retention was skipped.
Under ephemeral (and all) this let branched/edited/aborted messages and
shared links persist without isTemporary/expiredAt, outliving the chat.
Apply configMiddleware to those routes so retention is enforced
consistently. Add a getSharedLinkExpiration ephemeral test and keep route
test middleware mocks in sync.
The /fork and /duplicate routes read req.config.interfaceConfig but never
ran configMiddleware, so req.config was undefined and the retention mode
was not seen. Apply configMiddleware (as /import already does) so cloned
conversations honor the ephemeral retention policy.
The fork and duplicate paths created the import batch builder without the
runtime interface config, so under retentionMode "ephemeral" a fork or
duplicate of an existing permanent conversation skipped the forced
isTemporary/expiredAt fields and bypassed the policy.
Plumb req.config.interfaceConfig through forkConversation and
duplicateConversation into the builder so cloned records honor retention.
Extends the `retentionMode` interface option with a new `ephemeral` value
that forces every conversation to be temporary and applies expiration
deadlines to all data. Unlike `all` (which keeps chats visible until they
expire), `ephemeral` marks all chats temporary so they are hidden from
history and search, with the per-chat toggle locked on.
- Add RetentionMode.EPHEMERAL plus isAllDataRetention and
isForcedTemporaryRetention helpers
- Force isTemporary and expiry on conversations, messages, imports, and files
- Force the TEMPORARY_CHAT permission on so the locked indicator is shown
- Lock the temporary-chat toggle in the UI and force new/existing chats temporary
- Document the new mode in librechat.example.yaml
Pinning the scroll-to-bottom rib moved it out of the column, but scrubTo
kept enumerating ribs from the nav (messages + terminus) while measuring
the fraction against the column, which now spans the messages alone. Every
drag position mapped one rib late: pointing at the middle of the rail
scrolled to the message below the rib under the cursor.
Enumerate the column's own ribs for the proportional mapping and reach the
terminus by dragging past the column's bottom edge, where it now sits.
* 🛟 fix: Keep Loaded Message Content When a Resume Snapshot Is Empty
The sync handler guarded on `data.resumeState?.aggregatedContent` and then
assigned it unconditionally. An empty array is truthy, so a resume snapshot
carrying no content overwrote the content the messages query had already
loaded, leaving the message rendering as a bare cursor with no way to recover.
Treat an empty snapshot as non-authoritative: keep the loaded content and let
live deltas take over. A snapshot that carries content still wins, unchanged.
This is defense in depth rather than a root cause. A resume snapshot goes empty
when the conversation's job is replaced mid-flight (#14348) — because
`streamId === conversationId`, a second submission calls `createJob` on the same
key while the first run is still streaming. With this change that failure
degrades to stale-but-visible instead of destroying content already on screen.
* 🔒 fix: Scope Resume Content Preservation to Identity-Matched Responses
Codex P2: on a regenerate reload before the new run aggregated anything, the
server reports an empty snapshot under a response id not yet in the loaded
history. The parent-based fallback then lands on the answer being REPLACED, and
preserving its content seeded `syncStepMessage` with the stale response, so the
regenerated run's deltas appended to it instead of starting blank.
Preserve loaded content only when the row was matched by the server's declared
`responseMessageId` — the sole case proving the row belongs to this generation.
A fallback-matched row keeps the previous clear-on-empty behavior.
* 🧱 fix: Only Preserve Resume Content When the Row Actually Has Parts
A matched row with no `content` array would have been assigned `undefined`
instead of the snapshot's array. `MultiMessage` branches on `message.content`
truthiness to pick its renderer, and `[]` is truthy while `undefined` is not, so
that would have silently switched a streaming row from the content-parts
renderer to the text one.
Preserve only when the loaded row has a non-empty content array — the case the
guard exists for. Narrows the divergence from prior behavior further: it now
applies solely when there is real content to protect.
* 📌 fix: Pin Scroll-to-Bottom Rib in Message Nav
Render the terminus rib outside the scrolling rail, between the column
and the down chevron, so the scroll-to-bottom affordance stays in view
no matter how far the rail has scrolled.
- scrubTo enumerates ribs from the nav so drag-to-bottom still lands on
the terminus
- the pinned rib drives the shared preview itself on hover and focus,
since it is no longer covered by the column's pointer magnification
* 🖱️ fix: Keep Drag-Scrub Startable From the Pinned Terminus
Pointer-down on the pinned rib no longer reaches the column's handler now
that it renders outside the scrollport, so wire the same drag-start to the
wrapper. Dragging up from the bottom dot scrubs the thread again.
* 🧵 feat: Native Background Execution for Code Interpreter Tools
* 🩹 fix: Address Codex Round 1 (fallback dedupe, harvest failure, handle parsing)
* 🩹 fix: Live Completion Marker + Unkeyed Attachment Dedupe (Codex Round 2)
* 🎨 chore: Sort Imports + Widen Marker Type Comparison (CI)
* 🩹 fix: Stale-Harvest Guard, Error Marker Status, Faster Anchor Retry (Codex Round 3)
* 🧹 refactor: TS Harvest Module, Claim-Neutral Timestamps, Error Parity (Codex Round 4)
* 🩹 fix: Dispatch-Ordered Stale Guard, Foreground Downgrade, Error Wrapper Parity (Codex Round 5)
* 🩹 fix: Retry Past Unfinished Rows + Per-Call Attachment Dedupe (Codex Round 6)
* 🩹 fix: Writer-Dispatch Ordering, Scoped Live Upserts, Reaped-Task Wrapper (Codex Round 7)
* 🩹 fix: Wildcard toolCallId Matching for Bare Attachment Updates (CI)
* 🩹 fix: Claim-Insert Dispatch Stamp (Schema-Backed) + Scoped Status Markers (Codex Round 8)
* 🩹 fix: Pre-Write Ownership CAS + Agent-Scoped Part Patching (Codex Round 9)
* 🩹 fix: Insert-Path Ownership CAS + Agent-Routed Attachments (Codex Round 10)
* 🩹 fix: Agent-Scoped Marker Ids and Attachment Dedupe (Codex Round 11)
* 🩹 fix: Atomic File Commit and Sibling Preview Fan-Out (Codex Round 12)
- Replace the two-step claim-confirm CAS with an atomic conditional updateFile: the ownership predicate (no sourceDispatchedAt, or <= this write's dispatch order) moves into the update filter, removing confirmCodeFileOwnership and the lost-update window between check and write
- Thread agentId through createDownloadFallback so fallback download rows scope to the emitting agent like primary rows
- Fan terminal preview overlays out to every live attachment sharing the file_id in useAttachmentPreviewSync (sibling tool calls no longer stick on pending)
- Restore background artifacts through toStoredArtifact so the size bound applies on re-anchor
- Apply filterAttachmentsForPart to grouped tool-call attachments in ContentParts so handoff agents with colliding provider call ids do not cross-contaminate groups
* 🩹 fix: Agent-Scoped Live Upserts and Monotonic Dispatch Stamps (Codex Round 13)
- Scope the SSE attachment upsert and the useAttachments DB/live merge by agentId with the same wildcard semantics as toolCallId: distinct non-null agentIds stay separate entries, so handoff agents sharing a claimed file_id and a repeated provider tool id (call_0) no longer merge over each other's cards
- Extend the attachment identity key to fileKey::toolCallId::agentId and register less-specific key variants so bare and agent-less live records still dedupe after overlay
- Stamp background task createdAt from a strictly-increasing per-process dispatch counter: raw Date.now() can tie for same-millisecond dispatches and the stale-output guard accepts equal stamps (needed for idempotent re-commits), which would let an older task overwrite a newer task's committed file
Google rejects a YouTube video it cannot ingest with a generic
`400 INVALID_ARGUMENT` that names no cause, which LibreChat relayed
verbatim. Attribute the failure using request context instead: when a
Google/Vertex turn carried an injected YouTube video part and the
provider returns that generic rejection, map it to a typed error the
client localizes.
Verified against the live API: a public 9h15m video is refused this way
on gemini-2.5-flash, 3.5-flash, 3.5-flash-lite and 3.6-flash, including
at MEDIA_RESOLUTION_LOW, while a short video with an identical payload
succeeds. Duration is the dominant trigger; region and access
restrictions return the same response, so the copy leads with length
without overclaiming.
A duration preflight was evaluated and skipped: oEmbed does not expose
duration, leaving only watch-page scraping — a blocking call against
undocumented markup from rate-limited datacenter IPs that would fail
open and still need this mapping underneath.
* 🪟 perf: Virtualize Search Results and Stop the Per-Query Remount
* 🔧 fix: Type-safe globalThis cast in Search route test
* 🔑 fix: Stabilize Search Row Keys and Harden Virtualized Result Edges
Address Codex review findings on the virtualized search results view:
- Key rows by messageId (outer React key + CellMeasurer + cache keyMapper all
aligned) so React reconciles by message, not scroll slot.
- Compare title and conversationId in areSearchMessagePropsEqual so a rename or
refetch that keeps text/id intact still re-renders the row.
- Recompute cached heights on same-length content changes (file previews
resolving, refetch) and on font-size changes.
- Keep the aria-live announcement on the empty-results branch.
- Don't paginate the outgoing query while the user is still typing.
- Show the spinner during the initial debounce instead of a blank route.
* 🧵 fix: Reset Scroll, Remeasure Growth, and Footer-Pad Virtualized Search
Address the second Codex round on the virtualized search results view:
- Reset the List scroll to the top on a new query (results stay mounted via
keepPreviousData, so the List otherwise keeps the previous scrollTop and can
open a new search mid-list); a font-size change keeps the user's place.
- Re-measure a row when its content later grows/shrinks (tool/code output
expands, a late image loads) via a ResizeObserver that clears just that row's
cached height and recomputes from it.
- Give the load-more throttle trailing:false and cancel it when the query
changes, so a queued fetch can't page a stale search.
- Add a fixed trailing spacer row so the last result clears the bottom
gradient/spinner overlay.
* 🫥 fix: Gate Stale Search Results on Refetch State, Not Just Typing
Address the third Codex round: `isTyping` clears when the debounce publishes the
new query, but `keepPreviousData` keeps the old pages mounted until the new
request lands, leaving a window the typing-only guards missed.
- Derive `showingStale = isTyping || isPreviousData` and gate both the dimming
and pagination on it, so the outgoing results stay dimmed and don't page while
the new query is still fetching.
- Compare `unfinished` in areSearchMessagePropsEqual so a finish/cancel that
changes only that flag re-renders SearchContent's incomplete-response notice.
* 📐 fix: Invalidate Row Height Against the Cache and Compare clientTimestamp
Address the fourth Codex round on virtualized search:
- Compare each ResizeObserver height against the cached row height instead of
skipping the first callback, so a cached/fast-loading image that is already
taller than CellMeasurer's mount measurement still invalidates the stale
height (no more overlap/clipping of following rows).
- Compare clientTimestamp in areSearchMessagePropsEqual, since the row timestamp
falls back to it when createdAt is absent.
* 🕳️ fix: Spinner Over False Nothing-Found for Stale Empty Search Data
Address the fifth Codex round: when the previous search had zero matches,
keepPreviousData holds those empty pages (isPreviousData, isLoading false)
during the new request, so the loading gate missed it and flashed a false
"nothing found". Gate the spinner on `showingStale` too, not just isLoading/
isTyping.
* 🔗 fix: Preserve resource owner access when sharing (key share diff by stable id)
The share dialog diff (GenericGrantAccessDialog.handleSave) keyed added/removed
principals by `idOnTheSource`, which is inconsistent for the same user across
sources: getResourcePermissions returns `userInfo.idOnTheSource || _id` (the
external oid for OpenID/Entra users) while the people-picker returns the local
`_id`. The resource owner then appears in both `updated` and `removed`, and — since
updateResourcePermissions applies grants (upsert) before revocations (delete) — the
owner's own ACL entry is deleted when they add anyone to the share list. They then
get 403 on GET/edit/re-sharing their own resource.
Extract the diff into a pure computeShareChanges() helper keyed by
`id ?? idOnTheSource` (stable local id when present, external oid fallback for
principals not yet synced locally, e.g. unsynced Entra groups/users). Add unit tests.
Not reproducible with local-only users, where idOnTheSource falls back to _id and
both sources agree.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* 🔧 fix: address review — dedupe share diff by principalKey; drop test assertion
- computeShareChanges now diffs over the de-duplicated map values, so a principal
that appears more than once in the input (possible while the add/dedupe path still
keys on idOnTheSource) is never emitted multiple times in updated/removed.
- Drop the `as TPrincipal` assertion in the test helper — the literal is structurally
compatible with TPrincipal, so TypeScript validates the shape directly.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ⚡ feat: Add Gemini 3.6 Flash and Gemini 3.5 Flash-Lite Support
Adds first-class support for Google's Gemini 3.6 Flash (`gemini-3.6-flash`)
and Gemini 3.5 Flash-Lite (`gemini-3.5-flash-lite`) for both the Gemini API
(AI Studio) and Google Cloud/Vertex integrations.
- Context window (1M) in googleModels; API + cache pricing in tx.ts.
- Model dropdown (config.ts) and GOOGLE_MODELS examples for both integrations.
- Generalize the Gemini 3.5 Flash overrides into a flash-family handler that
strips deprecated temperature/topP/topK and applies each model's default
thinking level (3.6 Flash: medium, 3.5 Flash-Lite: minimal), with
longest-prefix resolution so flash-lite does not collide with flash.
Ref: https://ai.google.dev/gemini-api/docs/latest-model#api-changes-and-parameter-updates
* 🩹 fix: Strip unsupported penalty params for Gemini Flash family
Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash reject presencePenalty/
frequencyPenalty with HTTP 400 ("Penalty is not enabled for this model",
verified live). These pass through llmConfig via knownGoogleParams, so add
them to the flash-family strip list alongside the deprecated sampling params.
* 🩹 fix: Strip Flash-blocked params on custom Google endpoint path
For custom OpenAI-compatible endpoints with defaultParamsEndpoint=google,
getOpenAIConfig strips Flash-blocked params via getGoogleConfig but then
transformToOpenAIConfig re-applies raw addParams, undoing the strip. Filter
addParams through stripGeminiFlashBlockedParams before the transform so the
deprecated sampling / rejected penalty params cannot reach the provider.
* 🔧 chore: Update sharp package to version 0.35.3 in package-lock.json, api/package.json, and packages/api/package.json
* 🔧 chore: Update dependencies in package-lock.json to latest versions for @google/genai (2.13.0), @hono/node-server (1.19.14), fast-uri (3.1.4), hono (4.12.31), and svgo (2.8.3)
* 🔧 chore: Update dependencies in package.json and package-lock.json for @librechat/agents (3.2.67), @opentelemetry/sdk-node (0.221.0), and add new dependencies for @opentelemetry/propagator-jaeger (2.10.0) and protobufjs (7.6.5). Update monaco-editor version in client package.json to 0.56.0.
* 🔧 chore: Upgrade turbo package to version 2.10.5 in package.json and package-lock.json, and update schema reference in turbo.json
* 🩹 fix: Resolve CI breakage from bundled dependency bumps
Not related to the Gemini models — both are fallout from the dep bumps on
this branch:
- monaco-editor 0.56 changed IEditorHoverOptions.enabled from boolean to
'on' | 'off' | 'onKeyboardModifier'; update ArtifactCodeEditor to match
(mirrors the sibling occurrencesHighlight/matchBrackets pattern).
- sharp 0.35.3 fails resize+encode on a degenerate 1x1 PNG (vipspng: libpng
read error); the provider-file e2e fixture was 1x1, so use a 16x16 PNG.
Normal images are unaffected (verified 64x64 resize/encode/jpeg all OK).
* 📝 docs: Correct e2e image-fixture comment (bad IDAT CRC, not a sharp bug)
Root cause was the old 1x1 fixture's corrupt IDAT CRC (verified: IHDR/IEND
CRC OK, IDAT CRC BAD), which sharp 0.35.3's stricter libpng correctly rejects.
Not a dimension/resize edge case and not a sharp bug; comment now reflects that.
An applied steer renders nested inside the response, whose `relative` content
column becomes the steer's offsetParent, so its `offsetTop` is local to that
column rather than measured against the scroll content like top-level rows. The
rail compared that value against `scrollTop`, so once the viewport reached a
steer every jump/current-row decision was computed in the wrong coordinate
space — the "previous" chevron kept re-targeting the steer and got stuck.
- Add `entryTop(el, container)` that sums `offsetTop` up the offsetParent chain
until it leaves the scroll container, folding nested steers back into one
content-space origin (top-level rows collapse to a single hop)
- Use it for the four message-entry measurements (current row, offset cache,
jump previous/next); leave the column-rib offsets untouched
- Guard `getCurrentVisibleId` on a null scroll container
- Test a nested steer (local offset inside a positioned column) lands its rib at
the true thread position; fails with the old single-hop offsetTop
* fix: Use SSE to upload files in order to avoid idle timeouts. Idle timeouts can occur for example from gateways and other services like cloudfare when uploading large files. For example during rag processing the file is uploaded to librechat which then sends it to rag. While librechat is waiting for the embeddings to come back from rag the file upload is sitting idle. Gateways tend to want to cancel the upload with an http 408 , 504, or 524. This change uses SSE to perform the upload so that while librechat is sending the file to rag, it consistently sends back a heartbeat event to the client to keep the connection alive. This is especially useful when utilizing EMBEDDING_BATCH_SIZE in librechat rag which will allow rag to process signifigantly larger files without running out of memory.
* added tests to packages\api\src\files\sse.spec.ts in order to test the new sse.ts
* fix: Harden SSE file upload lifecycle
* style: Sort data provider imports
---------
Co-authored-by: Marc Amick <MarcAmick@jhu.edu>
Co-authored-by: Danny Avila <danny@librechat.ai>
* 🧠 fix: Restore Agent Memory Scope Control in Unified Builder
The Agent Builder redesign (#13952) surfaced memory as a Tools marketplace
item and stopped rendering SidePanel/Agents/Memory.tsx, orphaning the file and
removing the 'Keep memories separate for this agent' control shipped in #14084.
Only the render was lost: the locale keys, memory_scope on AgentForm, the
AgentPanel save path, and AgentSelect hydration all survived, which is why
setting memory_scope directly on the agent document still worked.
Restore it as a builtin item setting (the seam the new builder uses for
per-tool config): mark memory configurable so its row gets a cog, and render a
MemoryConfig branch in BuiltinSection mirroring ArtifactsConfig. Delete the
orphaned component so there is a single source of truth.
Resolves#14287
* 🧹 chore: Remove Orphaned com_agents_enable_memory i18n Key
The key labeled the enable checkbox in the deleted SidePanel/Agents/Memory.tsx.
The unified builder labels the catalog item via com_ui_memory, so it has no
remaining consumer and detect-unused-i18n-keys fails on it.
- Float the in-flight steer stack as a bottom-anchored overlay (`absolute
bottom-full`) so it no longer shrinks the message viewport and older messages
scroll behind it; a per-conversation Jotai height atom reserves an equal band
of bottom padding on the message scroll area so the newest message rests clear
- Collapse long steers to a ~128px preview with a bottom fade and a Show
more/Show less toggle, shown only once the content overflows the cap
- Sticky the per-steer options menu (`sticky top-2`) so it stays reachable while
scrolling through a tall, expanded steer
* 🧬 perf: Memoize Message Spine and Isolate Scroll-Button State
* ✅ test: Pin the message-row memo comparators against field drift
areMessageFieldsEqual and areMessageRowPropsEqual gate every message row's
re-render but had no direct tests. Add a completeness suite: a field-mutation
table asserts each compared field flips the comparator to false (a dropped
field fails its case), plus same-ref / equal-distinct-objects / nullish cases,
and the same shape for the row-props comparator including its delegation into
areMessageFieldsEqual.
* 🎛️ perf: Narrow Composer Subscriptions to Streaming State
* ✅ test: Cover Composer Subscription Refactor's Behavioral Changes
Add regression tests for the previously-uncovered changed behavior in the
composer-subscriptions refactor:
- useLatestMessageMeta: exact projected field set, null on empty cache, and
referential stability + no re-render across token-only cache writes.
- useGetLatestMessage: call-time tail read, stable callback identity with no
re-render on cache writes, Recoil-snapshot sibling-branch resolution, null
with no conversation.
- useSubmitMessage: reads the tail at call time and appends it to root when
missing (and does not when present or absent) — the reconcile branch the
prior test skipped via an early return.
- useHandleKeyUp: ArrowUp in an empty composer clicks the latest message's edit
control, with the null / missing-control / non-empty-composer guards.
- useAskAnswerMode (new spec): liveAsk is projected through the
findLiveAskUserQuestion select, null when empty/disabled.
* 🎨 style: Fix import order in useLatestMessage spec
* 🐛 fix: Dedup retried start-generation requests to prevent duplicate billing
A lost or reset start-generation response makes the client re-POST the
identical payload (up to 3x on network errors). The resumable-stream
controller had no idempotency: createJob unconditionally overwrote the
running job without aborting the prior one, so both requests ran full
LLM completions and both billed while the UI showed only one (#14339).
Add a stable per-submission clientRequestId (uuid, fresh per ask() so a
regenerate differs, reused across the start-generation retries) and an
atomic claim on the job store keyed by userId:clientRequestId. The first
request wins and generates; a retried POST loses the claim and receives
the original stream, which the client subscribes to and replays - no
second billed generation.
- IJobStore.claimIdempotencyKey/releaseIdempotencyKey (in-memory Map+TTL,
Redis single-key SET NX PX + GET Lua, cluster-safe)
- GenerationJobManager.claimGeneration/releaseGeneration (20m TTL)
- Controller claims before the concurrency check, dedups with a resumed
response, releases on start-failure/429
- clientRequestId threaded through TSubmission/TPayload/createPayload
* 🐛 fix: Harden start-generation dedup (Codex review)
Address three P2 findings on the idempotency path:
- Resume replay: a deduped retry now subscribes with resume=true so the
client replays prior content and any pending-action from the running
stream instead of only live events (cross-replica / HITL correctness).
startGeneration returns { streamId, resumed } and the response's
status:'resumed' drives the subscribe mode.
- Wait for the job record: a duplicate that loses the claim now waits
briefly for the winner to create the job before returning the stream
(a stream with no job 404s terminally). If the winner has not
materialized, return 503 SERVER_NOT_READY so the client retries via the
existing readiness path instead of attaching to a dead stream.
- Release only owned claims: track whether the request actually won the
claim; the 429 and init-error paths no longer release a claim owned by
another in-flight generation (fail-open path could erase it and
re-enable double billing).
Adds controller tests covering dedup, the 503 race fallback, win-then-
create, and claim-release ownership on 429 / fail-open.
* 🐛 fix: Don't trap deduped retries on missing job records (Codex review)
The previous round returned 503 SERVER_NOT_READY when a deduped retry's
job record was absent. But a missing job usually means the original
generation already completed and was cleaned up (cleanupOnComplete) — the
correct recovery is to return the stream and let the client's subscribe
404 handler refetch the persisted messages. The 503 instead trapped the
send in a readiness-retry loop until the client's window expired.
Keep the bounded wait (it still covers the job-about-to-be-created race)
but always return the resumed stream afterward; a gone/never-created job
recovers via the client's existing 404 path instead of being treated as
indefinitely starting. Updated the controller test accordingly.
* 🐛 fix: Gate deduped resume on claim age, not just job presence (Codex review)
Removing the 503 entirely (previous round) reintroduced the inverse race:
if the winning request stalls between claimGeneration and createJob, a
losing duplicate saw no job, returned status:'resumed' anyway, and the
client subscribed to a stream that did not exist yet — the 404 handler
tore the turn down while the winner went on to generate and bill with no
UI attached.
Distinguish the two missing-job cases by claim age (claimedAt now travels
on the claim value):
- fresh claim, no job yet → winner is still starting → 503 SERVER_NOT_READY
so the client retries via the readiness path (bounded, not indefinite).
- old claim, no job → the original already completed and was cleaned up
(or the winner died) → attach; the client's 404 handler refetches.
Tests cover both age branches.
* 🐛 fix: Scope dedup fail-open + keep resumed convos on 404 (Codex review)
- Fail-open only on claim acquisition: a store error while checking an
already-confirmed existing claim no longer falls through to createJob
(which would start a second billed generation during a Redis hiccup).
Once claim.existing is known, a job-lookup error returns 503 retry.
- Don't drop a resumed convo on 404: the optimistic-conversation cleanup
in useResumableSSE now runs only for fresh (non-resume) subscribes. A
deduped resume whose original completed and was cleaned up 404s, but its
conversation is persisted and must stay in the sidebar.
Adds a controller test for the job-lookup-error path (503, no createJob).
* 🐛 fix: Reconcile resumed convos on 404 instead of guessing (Codex review)
Round-4's !isResume guard fixed the completed-and-cleaned case (don't drop
a persisted convo) but left the inverse: a new-conversation retry deduped
to a claim whose original worker died before persisting still resumes,
404s, and — with removal skipped — leaves a phantom /c/<streamId> sidebar
entry.
Stop guessing keep-vs-remove on a resume 404. Reconcile against the
server: invalidate the conversations list so a real (persisted) convo
stays and a phantom is dropped. Fresh (non-resume) optimistic streams
still prune immediately. Adds a client test for the resume path.
* 🐛 fix: Finalize failed job before releasing its claim (Codex review)
In the initialization-error catch, the idempotency claim was released
before completeJob(streamId). A racing retry could win the released key
and createJob() the same streamId while this catch was still running, and
completeJob() (not guarded by the original createdAt) would then abort the
replacement. Finalize the failed job first, then release the claim.
Adds a controller test asserting completeJob precedes releaseGeneration.
* 🐛 fix: Clear claims on destroy + survive completeJob failure (Codex review)
- InMemoryJobStore.destroy() now clears the idempotencyClaims map, so a
reused/reconfigured store instance doesn't dedup a fresh start against a
torn-down job's stale claim.
- Init-error cleanup: completeJob() is swallowed so a store-hiccup
rejection can no longer skip the idempotency-key release and the
pending-request decrement (which would wedge the retry behind the claim
and leak the concurrency slot). A failed completeJob finalized nothing,
so releasing afterward still can't abort a later replacement.
Tests: claims cleared on destroy; release + pending decrement still run
when completeJob rejects.
* 🩹 fix: Route configured document types to RAG /text on agent upload
Restores pre-#11900 behavior for 'Upload as Text': when an admin narrows
fileConfig.text.supportedMimeTypes to a non-permissive allowlist that includes
a document type (docx/xlsx/pdf/ods/odt) and a RAG API is configured, the file
is sent to RAG /text instead of the built-in document parser.
The permissive default catch-all is excluded via isPermissiveMimeConfig, so RAG
deployments that never customized text handling keep the built-in parser. When
RAG is unreachable, parseText's new allowNativeFallback:false makes it throw so
the upload falls back to the built-in document parser rather than degrading a
docx/pdf to raw native-text bytes.
Fixes#14245
* style: sort imports in text.spec.ts (CI import-order)
* 🩹 fix: Scope RAG fallback catch to extraction only, not persistence
The configured-text branch wrapped both parseText and createTextFile in the
fallback try, so a persistence failure after a successful RAG extraction (size
guard, db.createFile, agent-resource mutation) was misread as RAG-unavailable
and retried with the built-in document parser, masking the real error and
risking a duplicate agent-resource mutation. Only the RAG extraction is now in
the fallback catch; a persistence failure surfaces as itself.
Addresses Codex P2 on #14345.
