graflo.hq.concurrency_gate¶
Decide how many batches of one data source may be in flight concurrently.
Casting is per-document pure and every real backend upserts idempotently, so overlapping cast/write of sibling batches is safe by default. A handful of configurations are genuinely order- or state-dependent; this module is the single place that names them and forces those sources back to strictly serial batch processing.
SerialReason
¶
Bases: StrEnum
Why a data source must process its batches strictly one at a time.
Source code in graflo/hq/concurrency_gate.py
bulk_load_enabled(conn_conf)
¶
Whether conn_conf declares an enabled native bulk-load config.
Source code in graflo/hq/concurrency_gate.py
effective_in_flight(runtime, params, conn_conf, *, bulk_enabled)
¶
Return (max_in_flight, reason) for one data source.
max_in_flight is params.max_in_flight_batches unless a serial
condition holds, in which case it is 1 and reason says why:
USER_OVERRIDE—max_in_flight_batches=1requested explicitly;DYNAMIC_EDGES— dynamic edge feedback mutates the shared edge config during casting, so document order across batches is semantic;BULK_SESSION— native bulk load appends to a single ordered session;EXTRA_WEIGHTS— weight enrichment reads the DB between the vertex and edge pushes (read-modify-write, racy across concurrent writers);BLANK_VERTICES— blank-edge resolution pairs source/target docs positionally within a batch, so batch composition and order matter;SECONDARY_IDENTITY— edges located by a secondary identity resolve their endpoints against database state, so a later batch's edges must not race an earlier batch's vertex writes;GRAFLO_BACKEND— the chunked-file backend rewrites its index on every writer close and is not safe for concurrent writers.