[BUG] flowiseai/flowise:3.1.4 fails to start (LangChain uuid, @smithy/eventstream-codec, connect-sqlite3) #6688

Activity

1. seth100

   added

   bugSomething isn't workingSomething isn't working

   on Jul 30, 2026
2. willhennegan commented on Jul 31, 2026

   

   willhennegan

   on Jul 31, 2026

   More actions

   I was about to report the same bug.

   • Fresh installation on an empty data directory.
   • Same failure with no persisted database.
   • flowiseai/flowise:3.1.2 fails.
   • flowiseai/flowise:3.1.1 succeeds using the exact same Compose file and host.

   Startup errors include:

   • Package subpath './utils/uuid' is not defined by "exports"
   • Cannot find module '@smithy/eventstream-codec'
   • TypeError: this.db.exec is not a function
3. J-Jaganathan commented on Aug 1, 2026

   

   J-Jaganathan

   on Aug 1, 2026

   More actions

   Confirming this same issue on Windows 11 with Docker Desktop, using the WSL2 backend.

   Environment:

   • Docker Desktop version: 4.84.0
   • WSL2 kernel: 6.18.33.2-microsoft-standard-WSL2
   • Ubuntu distro under WSL2, integration enabled
   • Host OS: Windows 11

   Steps taken:
   Pulled flowiseai/flowise:latest fresh (no prior container or volume on this machine). At the time of pulling, latest resolved to 3.1.4. Ran the container via Docker Desktop with default settings and no custom environment variables. The crash occurs during the session-store initialization step, before the server binds to any port, so port configuration is not a factor in reproducing it.

   Result:
   Identical failure sequence to the one reported here:

   • Package subpath './utils/uuid' is not defined by "exports" for @langchain/core
   • Cannot find module '@smithy/eventstream-codec'
   • TypeError: this.db.exec is not a function at connect-sqlite3, thrown from SessionPersistance.js

   The container reaches "All initialization steps completed successfully!" and then crashes on the session store init, which triggers a restart loop under Docker's default restart policy.

   This confirms the bug is not specific to Linux/Docker Compose setups, host filesystem permissions, or migration from an older database. A completely fresh Windows/WSL2/Docker Desktop install with a first-time pull reproduces it the same way.

   Pinning to flowiseai/flowise:3.1.3 resolved it for me as a workaround.
4. av commented on Aug 2, 2026

   

   av

   on Aug 2, 2026

   More actions

   Reproduced on flowiseai/flowise:3.1.4 (bare docker run -d flowiseai/flowise:3.1.4, fresh state) — identical logs, container exits(1) after All initialization steps completed successfully!.

   Root cause of the fatal TypeError: this.db.exec is not a function: a connect-sqlite3 API change between the two images.

   • 3.1.3 ships connect-sqlite3@0.9.16, where options.db is a filename and the store opens the database itself:

     this.db = options.db || this.table;
     // ... dbPath = (options.dir || '.') + '/' + this.db;

   • 3.1.4 ships connect-sqlite3@0.9.17, where options.db must be an already-opened sqlite3.Database instance:

     this.db = options.db;
     // ...
     this.db.exec('CREATE TABLE IF NOT EXISTS ...', ...)

   Flowise's dist/enterprise/middleware/passport/SessionPersistance.js still uses the 0.9.16 calling convention:

   dbStore = new sqlSession({
       db: 'database.sqlite',
       table: 'login_sessions',
       dir: homePath
   })

   so 0.9.17 calls .exec on the string 'database.sqlite' and crashes. Pinning connect-sqlite3 to 0.9.16 (or passing an opened sqlite3.Database per the new API) should fix this one; the @langchain/core ./utils/uuid and missing @smithy/eventstream-codec errors are separate non-fatal packaging regressions in the same image.

   Found while integrating Flowise into Harbor (https://github.com/av/harbor, commit f4e1281).
5. PiedPiper911

   added a commit that references this issue on Aug 5, 2026

   fix: create opened sqlite3.Database instance for connect-sqlite3 v0.9…

   ...

   b6f90a6
6. dblagbro

   added 2 commits that reference this issue on Aug 5, 2026

   Pin connect-sqlite3 to 0.9.16 -- root cause of upstream FlowiseAI#6688

   ...

   6ee6021

   Add CHANGELOG and document the Docker image findings in README

   ...

   fd4e8e6
7. dblagbro commented on Aug 5, 2026

   

   dblagbro

   on Aug 5, 2026

   More actions

   Root cause: connect-sqlite3@0.9.17, not Flowise 3.1.4

   This is not a 3.1.4 regression. connect-sqlite3@0.9.17 changed its constructor so this.db.exec is no longer a function, which throws during session-store setup at boot:

   TypeError: this.db.exec is not a function
     at new SQLiteStore (connect-sqlite3/lib/connect-sqlite3.js:56:17)
     at initializeDBClientAndStore (dist/enterprise/middleware/passport/SessionPersistance.js:96)
   

   Because the dependency is unpinned, any Flowise container built after 0.9.17 was published fails — at any version.

   Reproduced 2026-08-05:

   Build	connect-sqlite3	Result
   official flowiseai/flowise:3.1.3 (built earlier)	0.9.16	boots
   fresh build of that same flowise@3.1.3, today	0.9.17	crashes identically

   So the "3.1.3 works, 3.1.4 is broken" split is an artifact of when each image was built, not of anything that changed between the releases. Anyone rebuilding 3.1.3 to escape this hits the same crash.

   Fix

   Pin connect-sqlite3 to 0.9.16 — the last working constructor, and what every functioning official image actually shipped:

   RUN npm --prefix "$(npm root -g)/flowise" install --no-save connect-sqlite3@0.9.16

   @PiedPiper911's #6706 fixes the same defect in the TypeScript source, which covers source builds; this covers npm-installed container builds. Both are needed.

   Two other defects found while verifying

   1. The published images ship the wrong server package. Every official image contains flowise@3.1.2 regardless of tag:

   Image tag	Server actually shipped
   flowiseai/flowise:3.1.2	flowise@3.1.2
   flowiseai/flowise:3.1.3	flowise@3.1.2
   flowiseai/flowise:3.1.4	flowise@3.1.2

   docker/Dockerfile runs an unpinned npm install -g flowise. The version isn't part of the Docker layer cache key, so later builds reused the layer from when npm's latest was 3.1.2. flowise@3.1.3 and @3.1.4 are published correctly on npm — no image ever contained them.

   Practical impact: the security fixes released in flowise@3.1.3 are absent from every published image. Anyone can check their own instance:

   curl -s http://localhost:3000/api/v1/version

   If that returns 3.1.2 while you run a 3.1.3/3.1.4 image, you're affected.

   2. ARG NODE_VERSION=24 cannot build. better-sqlite3 fails under node-gyp (gyp ERR! not ok, node-gyp 8.4.1). Every published image runs Node v20.20.2, so CI must have been overriding the default — a plain docker build of the repo's own Dockerfile fails.

   Verified working

   With all three fixed, a build of flowise@3.1.4 reaches:

   ⚡️ [server]: Flowise Server is listening at :3000
   

   Two non-fatal node-load failures remain (@langchain/core ./utils/uuid → ReAct Agent; @smithy/eventstream-codec → AWS Bedrock). The server starts and serves normally.

   Full reproduction and fixes: https://github.com/dblagbro/flow-wiser — an unofficial community continuation fork, not affiliated with FlowiseAI or Workday. Posting here so the diagnosis is preserved on the issue before this repository is archived on 2026-08-10.
8. dblagbro

   added a commit that references this issue on Aug 6, 2026

   Lead the README with the Docker warning, and explain the fix in full

   ...

   58255df