deployable.target_unsupported: Deployable reaches a connection its target can't run

Deployable reaches a connection its target can't run.

Area 14, Tooling; not declinable; the next step is usually the agent's.

A deployable that declares a target is held to the connections it reaches, from the routes of the APIs it serves and the background work it runs: the disk and a service Jadpo runs (runs:) without host: aren't on Workers, SMTP on port 25 is blocked there, and only a Worker receives a Cloudflare queue or counts in Cloudflare's rate-limiting binding (area 11; area 16, "Rate limits"). One built for Workers that runs the schedules is held to them too: its tick is the minute's cron, so a schedule more often than once a minute is refused at its every: (area 12), and so is its client_address:: Cloudflare's CF-Connecting-IP is the only source a Worker reads (area 10, "Client addresses"). Each refusal names what to use instead. A bakery keeps its suppliers' price sheets on its disk:

example

use app { sheets }use bakery/entities { PriceSheet }use bakery/types { NewSheet, SheetKept }use bakery/failures { SheetNotKept }/// Keeps a price sheet as it was sent.action keep_prices(input: NewSheet) fails SheetNotKept -> SheetKept {    var sheet: File = attempt sheets.put(encoding.to_utf8(input.text), FileType.csv) {        storage_full: SheetNotKept    }    var filed: PriceSheet = PriceSheet.create {        set: {            sheet: sheet        }    }    return SheetKept {        id: filed.id    }}

and its edge, which serves the API that keeps them, is built for Workers:

example

application {    connections: {        limits: {            driver: Driver.cloudflare_rate_limits            namespace: 1001        }        sheets: {            driver: Driver.disk            path: "/var/lib/bakery/sheets"        }    }    deployables: {        edge: {            serves: [main]            target: Target.wasm        }    }    rate_limits: {        store: limits    }}

text

error: `edge` can't use `sheets` on Workers, which has no disk --> app.jadpo:15:21   | 7 |         sheets: {   |         ------ `Driver.disk`15 |             target: Target.wasm   |                     ^^^^^^^^^^^ built for Workers  reason: `sheets` keeps files on the server's own disk (`Driver.disk`), and a Worker has none; `edge` uses it through `keep_prices`.  next: Keep `sheets`'s files through a package over S3's API, such as Cloudflare R2, or use them from a `Target.native` deployable (agent)  rule: deployable.target_unsupported  help: https://jadpo.dev/docs/errors/deployable.target_unsupportedcheck failed: 1 error, 8 files

Another bakery checks its ovens' temperatures twice a minute:

example

use bakery/actions { check_ovens }/// Checks the ovens twice a minute.schedule oven_check {    every: 30s    run: check_ovens()}

and runs its schedules on Workers:

example

application {    connections: {        main: {            driver: Driver.postgres        }    }    deployables: {        edge: {            runs: [Trigger.schedules, Trigger.subscribers]            target: Target.wasm        }    }}

text

error: `edge` can't run `oven_check` every 30 seconds on Workers, whose cron runs once a minute --> domains/bakery/schedules/oven_check.jadpo:5:12  |5 |     every: 30s  |            ^^^ more often than once a minute  reason: A Worker ticks when Cloudflare's cron trigger runs it, once a minute at most, so a schedule due every 30 seconds would run late; `edge` runs `oven_check` because its `runs:` lists `Trigger.schedules`.  next: Give `oven_check` `every: 1m` or longer, or run `Trigger.schedules` in a `Target.native` deployable (agent)  rule: deployable.target_unsupported  help: https://jadpo.dev/docs/errors/deployable.target_unsupportedcheck failed: 1 error, 3 files

A third bakery reads its customers' addresses from its load balancer's X-Forwarded-For, and serves them from Workers:

example

application {    client_address: {        source: ClientAddressSource.forwarded_for        hops: 1    }    connections: {        limits: {            driver: Driver.cloudflare_rate_limits            namespace: 1001        }    }    deployables: {        edge: {            serves: [main]            target: Target.wasm        }    }    rate_limits: {        store: limits    }}

text

error: `edge` can't read the client's address from `X-Forwarded-For` on Workers --> app.jadpo:3:17   | 3 |         source: ClientAddressSource.forwarded_for   |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not read on Workers15 |             target: Target.wasm   |                     ----------- built for Workers  reason: Cloudflare writes the client's address in `CF-Connecting-IP` on every request, overwriting a caller's, and a Worker has no connection address of its own, so `cloudflare` is the only source a Worker reads; `edge` would refuse to start.  next: Use `ClientAddressSource.cloudflare` without `hops:`, or build `edge` with `Target.native` (agent)  rule: deployable.target_unsupported  help: https://jadpo.dev/docs/errors/deployable.target_unsupportedcheck failed: 1 error, 1 file