SQLite in-memory engines use SingletonThreadPool, giving every Session
the same underlying connection.  Repository methods create a new
Session via the factory, flush, then return — letting the Session go
out of scope.  Under high memory pressure (e.g. 32 parallel behave
workers) Python's garbage collector closes these orphaned Sessions,
issuing an implicit ROLLBACK on the shared connection and wiping
flushed-but-uncommitted rows written by other Sessions.

Replace the plain sessionmaker with scoped_session in the r2cov
Background step so that every factory() call returns the same Session
instance.  A single long-lived Session per scenario eliminates the
premature close/rollback window entirely.

Verified: 3 consecutive green runs with --processes 32 (10 099
scenarios, 0 failures each).

Refs: #570

@@ -0,0 +1,93 @@
+"""ASV benchmarks for session create DI wiring (bug #570).

@@ -0,0 +1,93 @@
+"""ASV benchmarks for session create DI wiring (bug #570).
+
+Measures the cost of creating a session through the ``PersistentSessionService``,

@@ -0,0 +20,4 @@
+from sqlalchemy import create_engine
+from sqlalchemy.orm import sessionmaker
+
+try:

@@ -0,0 +11,4 @@
+  Scenario: Session create produces a new session
+    When I invoke session-create-error create with no arguments
+    Then the session-create-error command should exit successfully
+    And the session-create-error output should contain "Session Created"

@@ -0,0 +23,4 @@
+  Scenario: Session create with custom actor succeeds
+    When I invoke session-create-error create with actor "openai/gpt-4"
+    Then the session-create-error command should exit successfully
+    And the session-create-error output should contain "openai/gpt-4"

@@ -0,0 +8,4 @@
+~~~~~~~~~~~~~~~~
+The bug is that ``_get_session_service()`` calls ``container.db()`` but the
+DI ``Container`` class has no ``db`` provider.  This raises
+``AttributeError: 'DynamicContainer' object has no attribute 'db'`` on every

@@ -0,0 +12,4 @@
+Suite Teardown    Cleanup Test Environment
+
+*** Test Cases ***
+Session Create After Init Should Not Error

@@ -0,0 +9,4 @@
+    Given a session-create-error CLI runner using the real DI path
+
+  @tdd @bug570 @wip
+  Scenario: Session create produces a new session

@@ -0,0 +14,4 @@
+    Then the session-create-error command should exit successfully
+    And the session-create-error output should contain "session_id:"
+
+  @tdd @bug570 @wip

@@ -0,0 +48,4 @@
+    """
+    # Store original _service so cleanup can restore it.
+    context.sce_original_service = session_mod._service
+    context.sce_tmpdir = tempfile.mkdtemp(prefix="session_create_err_570_")