Bugs found by the user-story tests

[SimonHeybrock]

Found while writing one test per user story (packages/essapps/tests/stories/, commit 954593f on architecture-sketch). Each item below was reproduced on that commit unless it says otherwise. The stories that disagree with the design are in a separate issue.

Records and recompute

• A chained record cannot be recomputed once the session that made its input has ended (story B5). Recomputing the producer creates a record with a new ID, which the consumer's request does not reference, so the consumer still fails. This contradicts "everything a session holds can be recomputed from records". test_b5_notebook_kernel_dies_mid_session passes only because it reruns the notebook's cells.

  loaded = client.run(LOAD, {'run': run})
  hist = client.run(HISTOGRAM, {'data': loaded.ref('data'), 'bins': 2})
  client.close()                # the kernel dies
  client = local(same_root, ...)
  client.recompute(hist)        # failed: "<id>.data: no copy; recompute the producer"
  client.recompute(loaded)      # completes, as a new record ID
  client.recompute(hist)        # still failed

• records(since=...) compares timestamps as ISO strings in SQL (story B6). A time with a non-UTC offset compares wrongly: records(since=one_hour_ago_in_utc_plus_2) returns nothing although every record is newer. A naive datetime has the same problem. There is also no upper bound, so "last Tuesday" needs filtering on the client.
• Reading a stored output looks up the record's spec in the registry (LocalBackend.output). Once an upgrade removes a spec version, the data outputs of records made with it raise KeyError, although old records should stay valid under their version (story D6). Not reproduced, because no example has a second spec version.

Batches

• batch.retry offers nothing for a batch made with the batch form (story D5). It keeps only members whose key is a dataset identity, so a batch keyed '250K', '260K' with a failed member returns {}.
• A batch cannot be cancelled by its label (story D3). operations.md says a batch is cancelled whole by its label, but the client has only cancel(record). The test loops over client.batch(label): one call per member, which is not atomic when a rule or a retry submits under the same label at the same time.
• A retry does not record that it is a retry. Records made by batch.retry have derives_from=None. Only Backend.retry sets it, and Client has no retry.
• A failure's kind is the exception's class name ('OSError', story D1), not one of the categories the design names: the workflow declared a reason, the code raised, or the framework could not run it. The batch table has no failure column, so a UI must read each record.

Publication

• allow_reused waives two checks: a result served by a held stage, and a workflow bound in process. The example registry binds in process, so every story test that publishes passes allow_reused=True although nothing was reused. Needs two flags, or one name that covers both.

Lifecycle

• Closing a local backend leaves its runner subprocesses running. They warn with ResourceWarning when garbage-collected, so D2 and H2 need a filterwarnings mark to restart a backend inside a test.
• Client.close() is not idempotent: a second call raises ValueError: I/O operation on closed file from RecordStore.close.
• drop of an output that a session holds only in memory has no effect (story H1). This matches its docstring ("evict an output's disk copy"), but a user who drops an output in a notebook sees nothing happen.

🤖 Generated with Claude Code