AbstractRuntime 0.10.0__tar.gz → 0.10.2__tar.gz

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

@@ -5,6 +5,35 @@ 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.2] - 2026-10-16
+
+### Changed
+
+- **Code nodes can import Python's standard library.** In the `sandbox` permission mode, `import json`, `re`,
+  `datetime`, `math`, `collections`, `itertools`, `statistics`, `textwrap`, `hashlib`, `urllib.parse`… now
+  work, at the top of the code and inside functions, in both the RestrictedPython lane and the fallback lane, and
+  inside the function bodies of flow function libraries. The sandbox still refuses third-party packages, private
+  (`_`-prefixed) modules, and the standard-library modules that reach the machine or go around the sandbox's own
+  checks: processes and the operating system (`os`, `subprocess`, `threading`, `signal`, `ctypes`, `platform`…), files (`io`,
+  `pathlib`, `shutil`, `tempfile`, `glob`, `sqlite3`, `logging`, and the parsers that read a file by path: `xml`,
+  `configparser`, `argparse`…), the network (`socket`, `http`, `urllib.request`, `smtplib`…), code loading or
+  interpreter internals (`sys`, `importlib`, `pickle`, `types`, `inspect`…) and attribute access by name,
+  evaluated annotations or frames (`operator`, `typing`, `functools`, `traceback`). A refusal names the module
+  and the reason; `from x import *`, relative imports and the `__import__` call stay refused.
+- **A Code node's return value must be JSON data.** `transform` returning a module, a function, a set, bytes or
+  any other value JSON cannot carry now fails with a sandbox error naming the value and where it sits
+  (`transform returned a value that cannot be sent as JSON: module 'time' at output[2]`), in every permission
+  mode, instead of a serializer crash later in the gateway's simulate reply or the run's persisted state. `full_access` (host policy) imports anything, as before.
+  The rule is applied twice: at compile time by `validate_code`, and at run time by the `__import__` bound into
+  the sandbox builtins. `get_code_execution_policy()` now lists `imports.denied_modules` for thin clients.
+
+## [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.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: AbstractRuntime
-Version: 0.10.0
+Version: 0.10.2
 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.2}/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.2}/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.2}/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.2}/pyproject.toml

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

abstractruntime-0.10.2/release-notes.md

@@ -0,0 +1,19 @@
+### Changed
+
+- **Code nodes can import Python's standard library.** In the `sandbox` permission mode, `import json`, `re`,
+  `datetime`, `math`, `collections`, `itertools`, `statistics`, `textwrap`, `hashlib`, `urllib.parse`… now
+  work, at the top of the code and inside functions, in both the RestrictedPython lane and the fallback lane, and
+  inside the function bodies of flow function libraries. The sandbox still refuses third-party packages, private
+  (`_`-prefixed) modules, and the standard-library modules that reach the machine or go around the sandbox's own
+  checks: processes and the operating system (`os`, `subprocess`, `threading`, `signal`, `ctypes`, `platform`…), files (`io`,
+  `pathlib`, `shutil`, `tempfile`, `glob`, `sqlite3`, `logging`, and the parsers that read a file by path: `xml`,
+  `configparser`, `argparse`…), the network (`socket`, `http`, `urllib.request`, `smtplib`…), code loading or
+  interpreter internals (`sys`, `importlib`, `pickle`, `types`, `inspect`…) and attribute access by name,
+  evaluated annotations or frames (`operator`, `typing`, `functools`, `traceback`). A refusal names the module
+  and the reason; `from x import *`, relative imports and the `__import__` call stay refused.
+- **A Code node's return value must be JSON data.** `transform` returning a module, a function, a set, bytes or
+  any other value JSON cannot carry now fails with a sandbox error naming the value and where it sits
+  (`transform returned a value that cannot be sent as JSON: module 'time' at output[2]`), in every permission
+  mode, instead of a serializer crash later in the gateway's simulate reply or the run's persisted state. `full_access` (host policy) imports anything, as before.
+  The rule is applied twice: at compile time by `validate_code`, and at run time by the `__import__` bound into
+  the sandbox builtins. `get_code_execution_policy()` now lists `imports.denied_modules` for thin clients.