langflow

この問題は LFX 1.13.0 で発生します。原因は、Table.smart_column_order() が、Pandas のラベルが整数、タプル、または None である場合でも、すべてのカラムラベルに対して .lower() と .startswith() を呼び出すことです。

マージされた修正では、content/system カラムのルールは文字列ラベルにのみ適用され、文字列以外のラベルは通常のメタデータカラムとして扱われます。PR fix: handle non-string labels in smart column ordering を含む LFX リリースにアップグレードしてください。

アップグレードできない場合は、SplitTextComponent を実行する前に文字列以外のカラム名を文字列に変更し、実行後に元の名前に戻してください。

# `pdf` は基盤となる 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()

# 必要に応じて元の文字列以外のラベルを復元する
result = result.rename(columns={v: k for k, v in label_map.items()})

生成された文字列名が既存のカラム名と衝突しないようにしてください。

メモリインジェスションのキャンセル修正を含むリリースにアップグレードするか、対応するパッチを適用してください。この問題は、ingest_memory_task が協調的なキャンセルの後に通常の辞書を返すために発生し、その結果 execute_with_status がジョブを成功として扱い、COMPLETED を永続化してしまいます。

ingest_memory_task 内の両方のキャンセルパスで、まず必要な部分書き込みのクリーンアップを実行してから、結果を返す代わりにジョブラッパーが認識するキャンセル例外を伝播させてください：

raise CancelledError("LANGFLOW_USER_CANCELLED")

この例外を送出する前に、メッセージへのスタンプ付与やインジェスションのメタデータ/カーソルの更新を行わないでください。execute_with_status は既にこの例外を CANCELLED にマッピングし、終了タイムスタンプを保持します。このバグは main の df9711c および release-1.13.0 の 33cedec で再現されています。回帰テストでは実際の SQLite トランザクションを使用し、書き込み前または書き込み中のキャンセル、クリーンアップ、およびカーソルが変更されていないことを検証します。

PR #15614 の修正を適用するか、その修正を含む Langflow リリースにアップグレードしてください。このパッチは、検証済みの pgvector テーブルを各プロセス内にキャッシュし、キャッシュミス時にはカタログを確認して、データベース全体の _ADVISORY_LOCK_KEY ではなく、作成対象の特定テーブルに対してのみアドバイザリロックを取得します。これにより、ナレッジベースごとの _remote_lock と相まって PgBouncer の接続を枯渇させていた、グローバルなブートストラップロックのキューが解消されます。デプロイ後は、既存の idle in transaction セッションをクリアするため、すべての Langflow インスタンスを再起動してください。すぐにパッチを適用できない場合は、停滞しているインスタンスを再起動し、同時インジェスションジョブを削減し、アクティブなインジェスション1件あたり最大2つのサーバー接続（リース接続1つと書き込み接続1つ）にヘルスチェック用の余裕分を加えた規模で PgBouncer/PostgreSQL をサイジングしてください。PgBouncer の接続上限が75の場合、パッチが適用されるまでは、アクティブなインジェスションの同時実行数を30以下に抑えてください。PgBouncer の default_pool_size/reserve_pool_size を増やしても、PostgreSQL の max_connections も同時に増やさなければ効果はありません。同一の共有ナレッジベースへの同時書き込みは引き続き直列化されるため、30秒のロックタイムアウトによる失敗を回避するには、そのナレッジベースへの書き込み元を減らしてください。

これはマージのサフィックス処理のバグです。この操作では、元のソース列である場合でも、_rightで終わるすべての出力列をPandasの一時的な重複列として扱います。回避策として、結合キーを除き、マージ前に_rightで終わるユーザー列をリネームし、マージ後に元の名前に戻してください。

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)

# Merge操作を実行し、その後名前を元に戻します:
result = result.rename(columns={v: k for k, v in renames.items()})

再現ケースでは、マージ前にvalue_rightをvalue_right_sourceなどの名前にリネームしてください。これにより、両方のテーブルにvalueが含まれる場合にPandasが生成するvalue_right列との衝突も防止でき、AttributeError: 'Table' object has no attribute 'dtype'によるクラッシュを回避できます。

恒久対応では、重複する右側の非キー列のみを衝突のない一時的な名前にリネームし、元の名前から一時的な名前への明示的なマッピングを保持し、それらの一時列のみをcoalesce／削除します。この修正は、現在のOperationsのマージと、保存済みフローで使用されているレガシーのTable Operations実装の両方に適用する必要があります。

この問題は、claim_queued_lease() とリクエストの再構築には成功したものの _enqueue() が例外を送出した場合に、BackgroundExecutionService.sweep_orphans_on_startup() で発生します。この例外は release_queued_lease() を呼び出さないまま抑制され、ジョブがエグゼキューターに一度も送信されていないにもかかわらず、行は新しいオーナーとハートビートを持つ QUEUED 状態のまま残されていました。

修正では、エンキューの失敗をログに記録し、該当するリースをそのオーナーとハートビートトークンを使って解放します。これにより compare-and-swap による所有権チェックが維持され、古いクレーマントが新しいリースを消去できないようになります。PR fix(background): release queued lease when startup enqueue fails を含む、パッチ適用済みの 1.13.x リリースにアップグレードしてください。

デフォルトのインプロセスバックエンド向けの一時的な回避策: リースが失効するまで待ってからプロセスを再起動し、一回限りの起動時スイープがジョブを回収できるようにします。キューストアを手動で変更する場合は、記録されたオーナーとハートビートトークンに一致するリースのみを解放し、リースカラムを無条件にクリアしないでください。