Skip to main content
New source defaults to authoring contract edition 11. The optional compatibility: { authoringContract: 'explicit-freshness' } marker explicitly declares that contract. Existing artifacts retain their pinned edition. Check, publish, and run use the same admitted snapshot.

​
Durable call keys are static

Durable call keys — the deepline.fetch key, the deepline.dataset key, the deepline.step id — must be static string literals. The key names a durable receipt, so check, publish, and replay have to agree on it before the body runs. A key computed at runtime cannot be resolved at check time and is rejected. This is an architectural constraint, not a style rule. A play cannot loop over a computed key, so it cannot page a large table with a helper like page(pageNumber). Unrolling one literal key per page is not a design at any real page count. Push the aggregation server-side and call it once: a SQL function, a view, or a provider endpoint that returns the whole result. Keep unrolled literal keys only for a handful of genuinely distinct calls. To fan out over rows, use deepline.dataset with a static key — the per-row receipt identity comes from the row, not from the key.

​
Durable HTTP batches

A static deepline.fetch key inside a loop is a warning because every iteration must still have distinct method, URL, body, or safe headers. One durable receipt must never stand in for every request. Keep the static fetch label. For a mutating batch, make the body distinct and use a replay-stable external Idempotency-Key such as ${deepline.run.id}:signals:${batchIndex}.

​
deepline.run.id

deepline.run.id is stable while Deepline retries or resumes one durable run. A separately submitted run receives a new id. Use it when deriving an external idempotency key for a sequence of batches.

​
Runtime capabilities