SIGN IN SIGN UP

chore(deps): remediate Mend scan findings on release-1.11.4 (backport of #14555) (#14562)

* chore(deps): bump datasets to 5.0.1

Mend flags datasets 4.8.5. The declared range (>2.14.7,<6.0.0) already
permitted 5.x; the lock had simply gone stale, so this is a lock-only
re-resolution with no transitive churn.

datasets is an optional extra with no first-party import in Langflow.

(cherry picked from commit 6a0c13fc727c8e30e73003b8d442a9c73db7ddfb)

* chore(deps): upgrade react-router-dom to v7.18.2

The three react-router advisories Mend reports against 6.30.4 have no fix
in the 6.x line -- CVE-2026-53669 and CVE-2026-53666 are patched only in
7.18.0, and CVE-2026-53668 (react-router-dom 6.30.2-6.30.4) has no 6.x
patch at all. 7.18.2 also covers GHSA-qwww-vcr4-c8h2.

The migration surface is small: Langflow uses createBrowserRouter with
createRoutesFromElements and no loaders, actions, fetchers, defer(), or
json(), so the v7 future flags that gate behavior changes do not apply.
The only v6-specific code was a test that opted into v7_relativeSplatPath
and v7_startTransition explicitly -- both are v7 defaults, so the prop is
dropped.

react-router v7 reads TextEncoder at module load and jsdom does not expose
it, which broke 14 suites at import time; polyfilled next to the existing
crypto/URL shims in jest.setup.js.

Verified: tsc --noEmit is byte-identical to the v6 baseline (284
pre-existing errors, zero new), vite build succeeds, and all 587 jest
suites / 6421 tests pass.

(cherry picked from commit f1c411108e2ed2c4b8ac646ade03b74194ff376d)

* fix(frontend): keep flow events posted just before mount visible

react-router v7 renders route updates in a transition, so the flow page can
paint before useFlowEvents remounts with the new flow id. The hook seeded its
`since` cursor with Date.now() at mount and the events API only returns events
strictly newer than `since`, so anything posted in that window was dropped for
good: the poll kept re-sending the same cursor and never saw the event.

That is what shard 38 hit here. The trace shows the test's POST landing ~0.2-0.5s
before the hook mounted on the new flow, so the agent banner never appeared --
deterministic, 8/8 attempts, while the same shard passed at the base commit.

Seed the cursor 10s in the past instead, and let the server's `settled` flag
decide what to do with what turns up: on the catch-up poll, events for a flow
that has already settled advance the cursor but stay silent, so finished work
does not flash a banner or trigger the settle-driven flow refetch.

(cherry picked from commit 4f52bcb6ac2f16c2ab7e2751e1126c86bb11bb40)

* test(frontend): wait for the new flow to load before pressing "/"

Second fallout from the router bump, same shape as the flow-events one: the
blank-flow click creates a flow and navigates, and under v7 the new canvas
mounts well after the click resolves -- 1.3s later in the failing trace, which
is 0.2s AFTER the test pressed "/".

The wait that was supposed to cover this does not: `sidebar-search-input` is
present on the flow we are LEAVING too, so it resolved against the outgoing
page. Focus went to that sidebar, the new flow's page then remounted, and the
input the assertion polls was a different, unfocused one -- "inactive", 8/8
attempts. It passed at the base commit and was already failing here before the
flow-events fix (run 1 attempt 1, rescued by the job-level retry).

Wait for the GET of the flow in the URL to land instead, so the test is on the
page it thinks it is on before it touches the keyboard.

(cherry picked from commit 08e10ee7a84cff274c494695565b7d5c51adbefa)
E
Eric Hare committed
a2569a8d401d090adc50615486cc12a64e18258c
Parent: ac4f247
Committed by GitHub <noreply@github.com> on 8/14/2026, 6:03:33 PM