Files
langflow/docs
Eric Hare 4dc9e28eb0 fix(initial_setup): upsert by (user_id, name) when loading flows from disk (#13132)
* fix(initial_setup): upsert by (user_id, name) when loading flows from disk

Langflow fails to start with IntegrityError on the unique_flow_name
constraint when LANGFLOW_LOAD_FLOWS_PATH is used in CI/CD pipelines and
the flow file's id differs from the DB record's id (e.g. nightly
upgrade, regenerated UUIDs, fresh DB). Manual DB intervention was the
only workaround.

Root cause: find_existing_flow only looked up by endpoint_name and id,
never by (user_id, name). The unique constraint is on (user_id, name),
so when those lookups missed, the loader fell through to INSERT and
PostgreSQL rejected it.

Fix:
- find_existing_flow now takes optional keyword args (user_id, name)
  and falls back to a (user_id, name) lookup when endpoint_name/id
  don't match. The endpoint_name branch is also scoped by user_id when
  supplied so it can't accidentally return another user's flow.
- upsert_flow_from_file passes name and user_id to find_existing_flow.
  When the match is by name (existing.id != file's flow_id), the DB id
  is preserved during the setattr loop -- rewriting it from under FK
  referrers was unsafe and was never required by the original logic.

Tests: 8 regression tests cover lookup precedence (id wins, endpoint
scoped by user, name fallback fires only when id misses), the
reporter's scenario (no IntegrityError on repeated import with
differing file ids), DB-id preservation on name-match, and a
no-regression case where matched-by-id behavior is unchanged.

Fixes the CI/CD upgrade failure reported in IBM Cloud Slack
(C06SUKEN3LJ thread 1777992833.170099).

* fix(initial_setup): fix matched_by_id on SQLite, improve update log message

Normalize existing.id to UUID before the matched_by_id comparison.
On SQLite, SQLAlchemy can return ids as strings; str == UUID is always
False, so matched_by_id would silently be wrong and the file id would
be dropped even on a genuine id-match.

Improve the update log to include the DB id and flow name alongside the
file's UUID so the CI/CD upgrade scenario (name-matched upsert with
differing UUIDs) is debuggable from logs.

* [autofix.ci] apply automated fixes

* fix: Preserve db id

* [autofix.ci] apply automated fixes

* feat: Add flag to control name matching overwrite

* [autofix.ci] apply automated fixes

* Flip the default value for the flag

* Update test_upsert_flow_from_file.py

* fix: Sqlalchemy-based crash on startup

---------

Co-authored-by: Jordan Frazier <jordan.frazier@datastax.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
2026-05-16 01:20:14 +00:00
..
2025-02-06 17:44:46 +00:00
2023-07-18 15:08:00 -03:00
2026-03-18 20:03:49 +00:00
2026-04-23 17:49:52 -07:00
2026-04-14 02:07:01 +00:00

Website

This website is built using Docusaurus 3, a modern static website generator.

Installation

$ npm install

Local Development

$ npm run start

This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.

Build

$ npm run build

This command generates static content into the build directory and can be served using any static contents hosting service, including npm run serve.

Import code snippets from the repo with a line range

To pull a slice of a file into the docs, source the content with raw-loader and present the code with the CodeSnippet component. For a working example, see the Components overview.

import CodeSnippet from "@site/src/components/CodeSnippet";
import customComponent from "!!raw-loader!@langflow/src/lfx/src/lfx/custom/custom_component/custom_component.py";

<CodeSnippet
  source={customComponent}
  startLine={41}
  endLine={74}
  language="python"
  title="CustomComponent metadata (from codebase)"
  showLineNumbers
/>

Docusaurus Versioning

The versioning configuration is found in docusaurus.config.js.

Versioning example for release version 1.9.x on top of 1.8.x:

  1. Before release, the docs in the active release branch should already be set to 1.8.x, the current version.
  2. When ready to release 1.9.x, create a branch and run npm run docs:version -- 1.9.0 to snapshot the current docs.
  3. After creating a new version, update docusaurus.config.js to include the 1.9.0 release:
docs: {
  lastVersion: '1.9.0',
  versions: {
    '1.9.0': {
      label: '1.9.x',
      path: '1.9.0',
    },
    '1.8.0': {
      label: '1.8.x',
      path: '1.8.0',
    },
  },
},
  1. Test the deployment locally:
npm run build
npm run serve
  1. Create a pull request to main, and merge to create your new release.
  2. To create version 2.0.x, repeat the process: update the active release branch docs to 2.0.x when you begin working on it, then when ready to release, run npm run docs:version -- 2.0.0, update docusaurus.config.js with labels using .x notation, and merge to main.
  • lastVersion = the most recent released version (shown as "latest" in the UI).

See the Docusaurus docs for more info.

Disable versioning

  1. Remove the versions configuration from docusaurus.config.js.
  2. Delete the docs/versioned_docs/ and docs/versioned_sidebars/ directories.
  3. Delete docs/versions.json.

References

Deployment

Using SSH:

$ USE_SSH=true npm run deploy

Not using SSH:

$ GIT_USER=<Your GitHub username> npm run deploy

If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the gh-pages branch.