AbstractRuntime 0.10.0__tar.gz → 0.10.1__tar.gz

{abstractruntime-0.10.0 → abstractruntime-0.10.1}/CHANGELOG.md

@@ -5,6 +5,13 @@ All notable changes to AbstractRuntime will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.10.1] - 2026-10-16
+
+### Changed
+
+- **The JSON run store answers "which runs are running or waiting" from an in-memory index.** Every such listing (`list_runs` / `list_run_index` with status running or waiting) used to glob and `stat()` every run file in the store on every call — 10,678 files on a long-lived store — and each `stat` releases the GIL, so the scan queued behind any busy thread: 0.2 s alone, 3 s with two concurrent, 67–147 s beside a generating model. The store now keeps the set of active run ids, built from one scan, maintained by `save()`, `delete()` and the creation journal, and re-verifies every candidate against disk at listing time, so a run that ended or vanished is never listed and a stale entry heals itself; a background rescan at most every 60 s catches a writer that bypasses the journal. The rows, their order, filters, limits and the `updated_at` sort are exactly the scan's — proven by a differential harness against a copy of a live store under concurrent writers and a busy thread, and by `tests/test_active_index.py`. `JsonFileRunStore(..., use_active_index=False)` keeps the plain scan.
+- The creation journal gains a `~<run_id>` line: a run that becomes active through one store object (resumed, re-opened, first save after a restart) is announced to every other store object on the same folder, like `+` for creation and `-` for deletion. Older readers ignore the line.
+
 ## [0.10.0] - 2026-10-15
 
 ### Added

{abstractruntime-0.10.0 → abstractruntime-0.10.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: AbstractRuntime
-Version: 0.10.0
+Version: 0.10.1
 Summary: AbstractRuntime: a durable graph runner designed to pair with AbstractCore.
 Project-URL: AbstractCore (website), https://www.abstractcore.ai/
 Project-URL: AbstractRuntime (GitHub), https://github.com/lpalbou/abstractruntime

{abstractruntime-0.10.0 → abstractruntime-0.10.1}/docs/api.md

@@ -125,6 +125,8 @@ Run index and creation (all built-in run stores, including the offloading wrappe
 - `list_run_index(status=, workflow_id=, session_id=, root_only=, limit=, oldest_first=, automation_id=, role=, session_kind=)`: lightweight rows carrying `automation_id`, `role`, `occurrence_index`, `session_kind` and `workspace_root` (the run's top-level `vars["workspace_root"]` as stored, stripped; `None` when absent); the three attribution filters take a value, a comma-separated string or a list; `root_only=True` returns turn roots (parent-less runs except automation controllers, plus automation occurrences)
 - `session_kinds(session_id) -> frozenset` and `latest_occurrence_row(automation_id)`: indexed lookups used by session attribution and automation listings
 - `JsonFileRunStore.warm_session_index()` builds the session and children indexes at host startup. Store objects and processes sharing one JSON run folder see each other's created and deleted runs through the creation journal `.runs_created.log`; v1 supports one writer process per store
+- `JsonFileRunStore` answers `list_runs` / `list_run_index` for `status=running` or `status=waiting` (without `session_id`) from an in-memory **active index**: the set of active run ids, built from one directory scan (at host boot through `warm_session_index()`, else on the first such listing) and kept current by `save`, `create_if_absent`, `delete` and the creation journal. Every candidate is re-verified against its file at listing time, so a run that ended or vanished is never listed. Rows, order (file mtime, then file name, then the final `updated_at` sort), filters and limits are the same as the directory scan's; a listing of a 10,000-run store costs milliseconds instead of a full scan. `JsonFileRunStore(..., use_active_index=False)` keeps the plain scan. `rescan_active_index()` reconciles the index with the directory in the caller's thread; a background rescan runs at most every `JsonFileRunStore.ACTIVE_INDEX_RESCAN_S` (60 s) to pick up writers that bypass the store. `list_due_wait_until` (the scheduler's due-wait poll) takes its candidates from the index too. Other listings (a terminal status, no status, a session scope) scan as before.
+- The creation journal (`.runs_created.log` in the run folder) carries one line per change another store object or process must learn about: `+<run_id>` created, `-<run_id>` deleted, `~<run_id>` became active again (resumed, re-opened, first save after a restart, or saved after another writer touched the file). Lines are written before the file change they announce; readers apply the lines they have not seen at their next lookup, and a line whose file has not landed yet (or does not read active yet) is re-checked until it does. Readers from AbstractRuntime 0.10.0 ignore `~` lines, and writers from 0.10.0 never write them: a re-open made by such a writer reaches other store objects through the periodic rescan.
 
 Common decorators:
 - `ObservableLedgerStore` for subscriptions (`src/abstractruntime/storage/observable.py`)

{abstractruntime-0.10.0 → abstractruntime-0.10.1}/docs/architecture.md

@@ -381,6 +381,10 @@ Invariants the design rests on:
 - **Turns are defined once.** `select_session_turns` decides which runs are a session's turns (parent-less runs
   except controllers, plus occurrences). History bundles, session replay, growing context and discussion seeds all
   use it, and `list_run_index(root_only=True)` returns the same turn roots.
+- **Active listings are indexed.** The JSON run store keeps the set of running and waiting run ids in memory
+  (one scan to build, then maintained by every save, create and delete and by the creation journal) and verifies each
+  candidate against its file when listing, so the gateway's polls read a few files instead of the whole folder while
+  returning exactly the scan's rows. See `docs/api.md` → "Run index and creation".
 - **Attribution is indexed.** Each run index row carries `automation_id`, `role`, `occurrence_index` and
   `session_kind`, derived from inline `vars._meta` that the offloading store never moves. `Runtime.start` uses
   `session_attribution` to anchor every root run in a discussion session to the discussion's validated root and its

{abstractruntime-0.10.0 → abstractruntime-0.10.1}/llms-full.txt

@@ -812,6 +812,10 @@ Invariants the design rests on:
 - **Turns are defined once.** `select_session_turns` decides which runs are a session's turns (parent-less runs
   except controllers, plus occurrences). History bundles, session replay, growing context and discussion seeds all
   use it, and `list_run_index(root_only=True)` returns the same turn roots.
+- **Active listings are indexed.** The JSON run store keeps the set of running and waiting run ids in memory
+  (one scan to build, then maintained by every save, create and delete and by the creation journal) and verifies each
+  candidate against its file when listing, so the gateway's polls read a few files instead of the whole folder while
+  returning exactly the scan's rows. See `docs/api.md` → "Run index and creation".
 - **Attribution is indexed.** Each run index row carries `automation_id`, `role`, `occurrence_index` and
   `session_kind`, derived from inline `vars._meta` that the offloading store never moves. `Runtime.start` uses
   `session_attribution` to anchor every root run in a discussion session to the discussion's validated root and its
@@ -991,6 +995,8 @@ Run index and creation (all built-in run stores, including the offloading wrappe
 - `list_run_index(status=, workflow_id=, session_id=, root_only=, limit=, oldest_first=, automation_id=, role=, session_kind=)`: lightweight rows carrying `automation_id`, `role`, `occurrence_index`, `session_kind` and `workspace_root` (the run's top-level `vars["workspace_root"]` as stored, stripped; `None` when absent); the three attribution filters take a value, a comma-separated string or a list; `root_only=True` returns turn roots (parent-less runs except automation controllers, plus automation occurrences)
 - `session_kinds(session_id) -> frozenset` and `latest_occurrence_row(automation_id)`: indexed lookups used by session attribution and automation listings
 - `JsonFileRunStore.warm_session_index()` builds the session and children indexes at host startup. Store objects and processes sharing one JSON run folder see each other's created and deleted runs through the creation journal `.runs_created.log`; v1 supports one writer process per store
+- `JsonFileRunStore` answers `list_runs` / `list_run_index` for `status=running` or `status=waiting` (without `session_id`) from an in-memory **active index**: the set of active run ids, built from one directory scan (at host boot through `warm_session_index()`, else on the first such listing) and kept current by `save`, `create_if_absent`, `delete` and the creation journal. Every candidate is re-verified against its file at listing time, so a run that ended or vanished is never listed. Rows, order (file mtime, then file name, then the final `updated_at` sort), filters and limits are the same as the directory scan's; a listing of a 10,000-run store costs milliseconds instead of a full scan. `JsonFileRunStore(..., use_active_index=False)` keeps the plain scan. `rescan_active_index()` reconciles the index with the directory in the caller's thread; a background rescan runs at most every `JsonFileRunStore.ACTIVE_INDEX_RESCAN_S` (60 s) to pick up writers that bypass the store. `list_due_wait_until` (the scheduler's due-wait poll) takes its candidates from the index too. Other listings (a terminal status, no status, a session scope) scan as before.
+- The creation journal (`.runs_created.log` in the run folder) carries one line per change another store object or process must learn about: `+<run_id>` created, `-<run_id>` deleted, `~<run_id>` became active again (resumed, re-opened, first save after a restart, or saved after another writer touched the file). Lines are written before the file change they announce; readers apply the lines they have not seen at their next lookup, and a line whose file has not landed yet (or does not read active yet) is re-checked until it does. Readers from AbstractRuntime 0.10.0 ignore `~` lines, and writers from 0.10.0 never write them: a re-open made by such a writer reaches other store objects through the periodic rescan.
 
 Common decorators:
 - `ObservableLedgerStore` for subscriptions (`src/abstractruntime/storage/observable.py`)

{abstractruntime-0.10.0 → abstractruntime-0.10.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "AbstractRuntime"
-version = "0.10.0"
+version = "0.10.1"
 description = "AbstractRuntime: a durable graph runner designed to pair with AbstractCore."
 readme = "README.md"
 requires-python = ">=3.10"

abstractruntime-0.10.1/release-notes.md

@@ -0,0 +1,4 @@
+### Changed
+
+- **The JSON run store answers "which runs are running or waiting" from an in-memory index.** Every such listing (`list_runs` / `list_run_index` with status running or waiting) used to glob and `stat()` every run file in the store on every call — 10,678 files on a long-lived store — and each `stat` releases the GIL, so the scan queued behind any busy thread: 0.2 s alone, 3 s with two concurrent, 67–147 s beside a generating model. The store now keeps the set of active run ids, built from one scan, maintained by `save()`, `delete()` and the creation journal, and re-verifies every candidate against disk at listing time, so a run that ended or vanished is never listed and a stale entry heals itself; a background rescan at most every 60 s catches a writer that bypasses the journal. The rows, their order, filters, limits and the `updated_at` sort are exactly the scan's — proven by a differential harness against a copy of a live store under concurrent writers and a busy thread, and by `tests/test_active_index.py`. `JsonFileRunStore(..., use_active_index=False)` keeps the plain scan.
+- The creation journal gains a `~<run_id>` line: a run that becomes active through one store object (resumed, re-opened, first save after a restart) is announced to every other store object on the same folder, like `+` for creation and `-` for deletion. Older readers ignore the line.