FlowiseAI/Flowise · error · InternalFlowiseError

Unhandled Edge Case

Error message

Unhandled Edge Case

What it means

Thrown inside the req.session.save callback in updateSubscriptionPlan() as an InternalFlowiseError (HTTP 400, UNHANDLED_EDGE_CASE) when Express saves the session and returns an error. It fires after a successful Stripe plan update when persisting the new user/subscription data back into the passport session fails (e.g. session store unreachable). Note: because the throw occurs inside the async callback of session.save, it will not be caught by the surrounding async function's try/catch or converted to a rejected promise — it will likely surface as an uncaught exception, so callers cannot rely on normal await-based error handling.

Source

Thrown at packages/server/src/IdentityManager.ts:465

                newPlanId === process.env.CLOUD_PRO_ID
            ) {
                loggedInUser.activeOrganizationProductId = newPlanId
            }

            req.user = {
                ...req.user,
                ...loggedInUser
            }

            // Update passport session
            // @ts-ignore
            req.session.passport.user = {
                ...req.user,
                ...loggedInUser
            }

            req.session.save((err) => {
                if (err) throw new InternalFlowiseError(StatusCodes.BAD_REQUEST, GeneralErrorMessage.UNHANDLED_EDGE_CASE)
            })

            return {
                status: 'success',
                user: loggedInUser
            }
        }
        return {
            status: 'error',
            message: 'Payment or subscription update not completed'
        }
    }

    public async createStripeUserAndSubscribe({ email, userPlan, referral }: { email: string; userPlan: UserPlan; referral?: string }) {
        if (!this.stripeManager) {
            throw new Error('Stripe manager is not initialized')
        }

View on GitHub (pinned to abe4a8601a)

Solutions

  1. Check session store health (Redis connectivity / DB) and capacity; restart or scale the store.
  2. Ensure the session store client (e.g. connect-redis) is configured with reconnect/error handling and adequate timeouts.
  3. Do not use MemoryStore in production — it leaks and is not fault-tolerant.
  4. Refactor the session.save call into a Promise and await it so errors propagate to the route's error handler instead of becoming uncaught.

Example fix

// before (throw inside callback — escapes async error handling)
req.session.save((err) => {
    if (err) throw new InternalFlowiseError(StatusCodes.BAD_REQUEST, GeneralErrorMessage.UNHANDLED_EDGE_CASE)
})

// after (promisify so the error is awaitable and reaches the error handler)
await new Promise<void>((resolve, reject) => {
    req.session.save((err) => {
        if (err) reject(new InternalFlowiseError(StatusCodes.BAD_REQUEST, GeneralErrorMessage.UNHANDLED_EDGE_CASE))
        else resolve()
    })
})
Defensive patterns

Strategy: try-catch

Validate before calling

// Health-check the session store at boot; surface readiness only when it is reachable
// e.g. for connect-redis: await redisClient.ping() before listening for traffic

Try / catch

// The current code throws inside the session.save callback, so a normal
// try/catch around the call will NOT catch it. Promisify the save first:
try {
    await new Promise<void>((resolve, reject) => {
        req.session.save((err) =>
            err ? reject(new InternalFlowiseError(StatusCodes.BAD_REQUEST, GeneralErrorMessage.UNHANDLED_EDGE_CASE)) : resolve()
        )
    })
} catch (e) {
    return res.status(503).json({ message: 'Session could not be persisted' })
}

Prevention

When it happens

Trigger: The session store (Redis/MemoryStore/DB) is down or errors during save after a plan change; the session payload exceeds the store size limit; a serialization error in passport; the connection to the session store dropped mid-request. Because the throw is in the callback, it typically becomes an uncaughtException rather than a route-level error.

Common situations: Redis session store outage; MemoryStore used in production (not designed for it) and hitting limits; network blip to a remote session store; concurrent requests mutating the same session.

Related errors


AI-assisted analysis of FlowiseAI/Flowise@abe4a8601a (2026-08-12). Data as JSON: /api/errors/8353aa10d701fd91. Report an issue: GitHub.