langflow

This occurs in LFX 1.13.0 because Table.smart_column_order() calls .lower() and .startswith() on every column label, even when Pandas labels are integers, tuples, or None.

The merged fix applies content/system column rules only to string labels; non-string labels remain normal metadata columns. Upgrade to an LFX release containing the PR fix: handle non-string labels in smart column ordering.

If you cannot upgrade, rename non-string columns to strings before running SplitTextComponent, then rename them back afterward:

# Assume `pdf` is the underlying pandas DataFrame
label_map = {
    c: str(c)
    for c in pdf.columns
    if not isinstance(c, str)
}

pdf = pdf.rename(columns=label_map)

component.set(
    data_inputs=DataFrame(pdf),
    text_key="text",
    separator="\n",
    chunk_size=6,
    chunk_overlap=0,
    keep_separator="False",
    clean_output=False,
)
component.split_text()

# Restore the original non-string labels if needed
result = result.rename(columns={v: k for k, v in label_map.items()})

Ensure the generated string names do not collide with existing column names.

Upgrade to a release containing the memory ingestion cancellation fix, or apply the corresponding patch. The problem occurs because ingest_memory_task returns a normal dictionary after cooperative cancellation, causing execute_with_status to treat the job as successful and persist COMPLETED.

In both cancellation paths in ingest_memory_task, perform required partial-write cleanup first, then propagate the cancellation exception recognized by the job wrapper instead of returning a result:

raise CancelledError("LANGFLOW_USER_CANCELLED")

Do not stamp messages or advance ingestion metadata/cursors before raising this exception. execute_with_status already maps this exception to CANCELLED and retains the finished timestamp. The bug was reproduced on main at df9711c and release-1.13.0 at 33cedec; regression tests use real SQLite transactions and verify cancellation before or during writes, cleanup, and unchanged cursors.

Apply the fix from PR #15614, or upgrade to a Langflow release containing it. The patch caches verified pgvector tables in each process, checks the catalog on a cache miss, and takes an advisory lock only for the specific table being created instead of the database-wide _ADVISORY_LOCK_KEY. This removes the global bootstrap-lock queue that combined with the per-knowledge-base _remote_lock to exhaust PgBouncer connections. After deploying, restart all Langflow instances to clear existing idle in transaction sessions. If you cannot patch immediately, restart the stalled instances, reduce concurrent ingestion jobs, and size PgBouncer/PostgreSQL for up to two server connections per active ingestion—one lease connection and one write connection—plus headroom for health checks. With a 75-connection PgBouncer limit, keep active ingestion concurrency around 30 or lower until patched. Increasing PgBouncer default_pool_size/reserve_pool_size only helps if PostgreSQL's max_connections is also increased. Concurrent writes to the same shared knowledge base remain serialized; reduce writers to that knowledge base to avoid the 30-second lock-timeout failure.

This is a merge suffix-handling bug: the operation treats every output column ending in _right as a temporary Pandas duplicate, even when it is an original source column. As a workaround, rename user columns ending in _right before merging, excluding join keys, and restore them afterward:

merge_keys = {"id"}
renames = {
    c: f"__orig_{c}"
    for c in left_dataframe.columns
    if c.endswith("_right") and c not in merge_keys
}
left_dataframe = left_dataframe.rename(columns=renames)

# Run the Merge operation, then restore names:
result = result.rename(columns={v: k for k, v in renames.items()})

For the reproduction case, rename value_right to something such as value_right_source before the merge. This also prevents the collision with Pandas' generated value_right column when both tables contain value, which causes the AttributeError: 'Table' object has no attribute 'dtype' crash.

The permanent fix renames only overlapping right-side non-key columns to collision-free temporary names, keeps an explicit original-to-temporary mapping, and coalesces/drops only those temporary columns. The fix must be applied to both the current Operations merge and the legacy Table Operations implementation used by saved flows.

This occurs in BackgroundExecutionService.sweep_orphans_on_startup() when claim_queued_lease() and request reconstruction succeed, but _enqueue() raises. The exception was suppressed without calling release_queued_lease(), leaving the row in QUEUED with a fresh owner and heartbeat even though the job was never submitted to the executor.

The fix logs the enqueue failure and releases that exact lease using its owner and heartbeat token, preserving compare-and-swap ownership checks so a stale claimant cannot clear a newer lease. Upgrade to a patched 1.13.x release containing the PR fix(background): release queued lease when startup enqueue fails.

Temporary workaround for the default in-process backend: wait until the lease becomes stale, then restart the process so the one-shot startup sweep can reclaim the job. If modifying the queue store manually, release only the lease matching the recorded owner and heartbeat token; do not unconditionally clear lease columns.