v4.2.2

v4.2.2 (2026-10-11)

Fixed

• The 3.2.0 to 4.0.0 upgrade (upgrade_to_4_0_0) places rows in batches. The embeddings, docs and
  edge-vector steps sent one SELECT, INSERT..SELECT or INSERT+DELETE per row; on Mindwalk's copy of live
  data (206K node vectors, 448K docs, 299K edge vectors) the dry run took 82 minutes and the apply was
  killed after 9 hours. Graphs are now read in one statement per step, rows are moved 400 at a time in
  one transaction per batch (the watermark that makes a killed pass resumable still names exactly the
  batches that completed), vectors no edge asserts go to quarantine in one statement, and only rows a
  resolver must decide stay per-row. The report is unchanged.
• The real cost of the upgrade was the dedupe, not the per-row placement. The rekey ran
  DELETE FROM rdf_labels WHERE %ID NOT IN (SELECT MIN(%ID) ... GROUP BY ...), which re-evaluates its
  subquery per row: 10.5 s for 10,000 labels, 49 s for 20,000 (quadratic), so Mindwalk's 653K labels meant
  hours. It now visits only the key groups that hold a copy, one DELETE each. The dry run's duplicate
  count (EXISTS per row) is one grouped read. Measured: the whole embeddings step for 80,000 vectors and
  labels went from minutes-and-growing to 15.9 s, linear. A statement with more than 100 bound
  parameters is sent with its values written in, because stmt.execute(*400 params) dies with
  <STACK> under irispython, and the declared vector width is now read from the $LIST an embedded
  cursor returns (the width lookup found nothing there, which is the "declares no vector width" error).
• rekey_kg_node_stores failed under irispython (createIRIS does not exist there); it now uses
  EmbeddedIRIS.
• The embeddings step refused a legacy table that initialize_schema adopted with no recorded width. It
  now measures the width from a stored vector.
• A batch compile that fails on Build 154 (Graph.KG.MCPToolSet: "MCPTools has not had inheritance
  resolved") is retried class by class before the deploy is called failed.
• delete_node returned False and Arno detection was silently off inside IRIS (since 4.2.0). The
  engine asked "is this class/method compiled?" with %Dictionary.CompiledClass.%ExistsId, which raised
  AttributeError under embedded Python and was read as "absent": Graph.KG.Eraser looked missing, so
  delete_node took a fallback that returned False, and Graph.KG.ArnoAccel looked missing. These
  probes (Arno, Eraser methods, the ledger guard) are now a SELECT on %Dictionary and work from every
  host (iris_vector_graph/_dictionary.py).
• The wgproto worker segfault (4.2.1) was the % -> _ method-name mapping, not the execute
  refactor (Mindwalk bisected it on Build 154). Through the CSP/wgproto Callin worker a %-method such as
  %Dictionary.CompiledClass.%ExistsId (stores/iris_sql_store.py) or %Routine.Exists
  (_engine/schema.py) that now really runs crashes the worker (signal 11); under 4.2.0 the lookup raised
  AttributeError and the caller fell back. EmbeddedIRIS is literal again by default; only the class deploy
  (EmbeddedIRIS(py_names=True)), which irispython needs for %New, spells them with _.
• EmbeddedCursor.execute runs the statement in its own frame again, as in 4.2.0. 4.2.1 moved it into a
  helper that returned the result set, and Mindwalk bisected a segfault of the wgproto worker on every
  engine call to embedded.py. This is the suspected cause, not a reproduced one: the fault does not
  occur under irispython or a terminal session.