[Bug] File-producing task steps can duplicate artifacts after interruption #32

What happened?

Several file-producing workflows use this ordering:

perform file effect → receive random artifact ID → checkpoint/cache that ID

Because Files.import() creates a new randomUUID(), an interruption after the file is created but before the durable task/cache receipt is saved can cause the same logical operation to create another artifact when the task is retried.

I found the same boundary in multiple current paths on main (82ff35b):

1. Document workflow

   AgentService.document() calls:

   files.fill(...) → filled.id → ctx.checkpoint({ state.filledId, artifactIds })

   If the process/lease is lost after files.fill() commits the new PDF but before the task checkpoint, recovery sees no state.filledId and fills the original again, producing another random-ID PDF.

2. Model fill_pdf tool

   The generic cached() helper executes the operation first, then writes the result into state.operations and checkpoints it:

   operation() → operations[key] = result → checkpoint()

   So the cache prevents replay only after the post-effect checkpoint succeeds.

3. Attachment import

   WorkspaceService.importAttachment() checks the imports mapping, then calls files.import(), then persists the mapping. A crash between import and mapping persistence can also create a second artifact on retry.

The underlying invariant seems to be:

one logical file-producing operation should have one durable operation identity, independent of how many execution attempts occur.

This is similar to the existing write-safety discipline around reviewed external actions and computer operationId, but file effects currently rely on a receipt written after the effect.

Steps to reproduce

A deterministic regression could inject failure immediately after the file effect but before its task/mapping checkpoint.

For the document path:

1. Create a task with a fillable source PDF and valid fields.
2. Allow files.fill() to complete and persist its output.
3. Fail the following ctx.checkpoint().
4. Recover/retry the task.
5. Assert that exactly one filled artifact exists for that logical fill operation.

Current behavior should re-enter with no state.filledId and call files.fill() again, yielding a second random artifact ID.

The same failure injection can be applied around cached("fill_pdf", ...) and importAttachment().

Commit or release

82ff35b912e4a08c435d29278631c95445adf658

Platform

API or worker

Environment and safe logs

Code-path audit against current main; I have not claimed a local executable reproduction because this environment cannot run the repository.

I would avoid fixing this only by moving the checkpoint earlier, because that would create the opposite failure mode (receipt says complete before the file exists). A durable operation identity / resumable file receipt seems like the safer abstraction. The smallest implementation might be a deterministic idempotency key accepted by file-producing operations, but the filesystem + DB recovery semantics should be decided explicitly.

AI-use note: I used an AI assistant to trace the file-effect/checkpoint ordering and draft this report; I verified the three cited paths against current source before filing.