Hold a subject

The physical worldScanHTTPholdsubjectsubject_stalehold.show

The item scan writes nothing: it holds the item on the station so the next scan knows what it is acting on.

The situation

A two-scan gesture needs memory between the scans. The first scan names an item, the second names where it goes. The station has to carry the first scan forward without trusting itself.

The recipe

A hold step locates the row and answers held with a subject: the code, the row id, a label, an expiry, and what to scan next.

{ "query": { "roles": ["packing"], "status": "pending" },
  "verb": "hold",
  "params": { "hold": {
    "ttlSeconds": 300,
    "label": "{item.orderId}",
    "headline": "{item.boxCode}",
    "subline": "{item.stationName}",
    "expect": { "schemes": [16], "prompt": "Scan each item for this order." },
    "show": "items"
  } } }

The station keeps the subject in memory and sends it back with the next scans as subject: { code, escalationId }. Scanning another item replaces it, and it lapses on its own after ttlSeconds (default 45). With hold.show naming a roster field of the held row’s form, the station renders that list under the hold card and ticks entries in as scans land. Steps gated by subject: { schemes: [12] } run only while a subject from that scheme is held, and read it through the {subject.<facet>} template bag.

The guarantee

A hold writes nothing and spends no badge use. The server trusts nothing about the subject: each request re-parses its code, re-reads the row under the station’s read scope, and requires it to still carry the code’s target and be pending. A subject that fails is stale. Steps that need one are skipped, and when nothing else matches the answer is subject_stale with clearSubject: true. See Scan codes.

The physical world