# `type.batch_input`

An `Input` or a route placeholder holds a batch type, a `File` or a `FileContents`, or what a provider or a queue sends holds a `File` or a `FileContents`, which only the runtime builds.

Area 12, [Background work](/docs/jobs-and-events.md); not declinable; the next step is usually the agent's.

Only the runtime builds a batch type, and `batches.status` and
`batches.cancel` find a run by its `id` alone, so no request carries one:
an `Input`, read from a body or a query string, and a route's placeholder
may not hold a `BatchRun`, a `BatchProgress`, a `RowProblem` or an
`ImportSummary`, however deep. A run comes from
`batches.each`, or from a field the caller may read where the
application kept it. No request carries a `File` either, since it would name
any file's store and key; take the `id` of the record that keeps it instead.
Nothing else from outside carries one: an operation's `output:` or
`wire_output:`, a webhook's event and an event a queue lists are refused the
same way. The same goes for `FileContents`, which only `store.read` builds, so
no request or answer can be read as one; bytes from outside are `Bytes`:


```jadpo
type StopSweep = Input {
    shelf_run: BatchRun
}

action stop_sweep(request: StopSweep) -> Unit {
    batches.cancel(request.shelf_run)
}
```

```text
error: `StopSweep.shelf_run` holds a `BatchRun`, which no request carries
 --> main.jadpo:2:16
  |
2 |     shelf_run: BatchRun
  |                ^^^^^^^^ a `BatchRun`
  reason: Only the runtime builds a `BatchRun`: a run comes from `batches.each`, or from a field the caller may read where the application kept it, and `batches.status` and `batches.cancel` find it by its `id` alone. A request that named one could read or stop any run.
  next: Take the `id` of the record that keeps the run, and read the `BatchRun` from its field (agent)
  rule: type.batch_input
  help: https://jadpo.dev/docs/errors/type.batch_input

check failed: 1 error, 2 files
```
