609 - One run per event: an automation that answers each return

• 601Do not spend AI on what a script can doThe automation gap, what integration platforms and laptop scripts each cost, and the division of labor: a script for the deterministic part, the model for writing it and for judgment.
• 602The agent writes the first scriptThe loop from a recorded draft through tests to the save, what a save requires, what validate and a dry run report, the dialect’s deliberate absences, the traps that fail a draft, and the script’s page in the portal.
• 603Outputs: feeds, reports, and dashboards that refresh themselvesOutput identity across runs, tables and documents, the semi-dynamic dashboard and its data region, the referencing pattern, version caps, and delivery to a bucket drop.
• 604Running it: by hand, from the portal, and on a scheduleFour triggers, the cadence builder, the pinned fire date, what a schedule guarantees, and the run history with every trigger, duration, output, and log.
• 605What a run may do, and the record it leavesThe authority a run carries, what a save refuses, why the language cannot reach out, the lifecycle, ownership and transfer, and the administrator’s view.
• 606Scripts as skills: the weekly review the agent runs on your businessThree scripts attached to one prompt, the agent running them and reading the outputs against the knowledge graph, and a weekly list of action items with the figures behind them.
• 607Events in: a webhook source, its table, and an automation that reads itCreating a source, presets for known senders, what a sender is told, the table that serves events from acknowledgement, compaction and retention, the Webhooks page and its alerts, and the two ways an automation reads events.
• 608Results out: notification channels and signed delivery to other systemsChannel kinds and who may send to them, sending from a session and from an automation, the delivery history and the retry rule, the JSON envelope a system routes on, signed requests, and delivery to another deployment.
• 609One run per event: an automation that answers each returnNaming a source, the event a run reads, the run history with each event id, bursts and arrival order, a failed event run that alerts and is not replayed, and when a scheduled batch fits better.
• 610A mailbox as a source: filing the mail other systems sendA mailbox Plexara reads, allowed senders and sender authentication, one row per message and a file per attachment, text marked external, a filing automation, and the limits: no OCR.
• 611When an automation fails at 2 a.m.One incident instead of a message per failure, the recovery message, the operations channel, causes and what is retried within a run, and the agent’s briefing at the next session.

The source

pos-returns

A webhook source an administrator created beside pos-sales. Each request carries a batch of returns, split into one event per return, with the sale id as the event id and the store id as the key. Its sender connection names its token as a stored secret.

The sender

ACME POS sales simulator

The same simulator 607 follows. After it posts each batch of sales to pos-sales, it posts the batch’s returns, about one in twenty-five sales, to pos-returns.

The automation

acme-pos-return-event-609

Names pos-returns as its event source and runs one at a time, queued. Each run counts the store’s returns in the 24 hours up to this one and flags the return when it is $250 or more, or the store’s third in a day.

Where a flag goes

ops-events

The JSON webhook channel from 608, signed by its connection and received by the ops-events source, so a system can route on data.type and a person can read the body.

def handle(event):
    ret = event["payload"]
    if ret.get("event") != "sale.returned":
        return {"sale_id": ret.get("sale_id"), "flagged": False, "skipped": "not a return"}
    day = store_day(ret, event["received_at"])
    reasons = reasons_for(ret, day)
    if reasons:
        platform.notify(
            channel = "ops-events",
            title = "Return to review at %s" % ret["store_name"],
            body = "Sale %s was returned for $%s (%s). Flagged for %s." % (...),
            key = "returns-watch:%s" % ret["store_id"],
            data = {"type": "pos.return.flagged", "sale_id": ..., "reasons": reasons},
        )
    return {"sale_id": ..., "store": ..., "amount": ..., "returns_24h": ...,
            "flagged": len(reasons) > 0, "reasons": reasons}

def main():
    if run.event == None:
        platform.result({"flagged": False, "skipped": "started without an event"})
        return
    platform.result(handle(run.event))

# store_day counts the store's returns stored in the 24 hours before this
# one, excluding this event id, and adds this one.

manage_script update
  name          acme-pos-return-event-609
  event_source  pos-returns
  exclusive     queue

-> status   updated
   message  Saved, and this version is what runs now: it presents the roles
            you held when you saved it, and any schedule fires it.

manage_script runs  acme-pos-return-event-609

   trigger  event_source  event_id                         status     duration
   event    pos-returns   dpx_73252d4f…-0008               succeeded  279 ms
   event    pos-returns   dpx_73252d4f…-0020               succeeded  203 ms
   event    pos-returns   dpx_733c9b2c…-0038               succeeded  201 ms
   event    pos-returns   dpx_733c9b2c…-0048               succeeded  213 ms
   event    pos-returns   dpx_109c51c1…-0005               succeeded  186 ms

manage_script get_run  dpx_475722ec…

-> trigger       event
   event_source  pos-returns
   result        {"sale_id": "dpx_5396c560…-0002", "store": "ACME Store #165",
                  "amount": 178.34, "flagged": false, "reasons": []}

1. 01

   One event, one run

   A run is made once for each event id. A delivery the sender retries, or two servers noticing the same event, makes no second run.

2. 02

   The sender never waits for the automation

   The run is queued in the same step that stores the event, before the sender is answered, and executes afterwards on the platform’s workers. A slow or failing automation cannot slow the sender down.

3. 03

   A burst is bounded

   An automation holds at most 100 event runs waiting. An event past that is recorded as a skipped run whose reason says the queue was full and the event is still in its source, and the Events section counts the week’s skips.

4. 04

   One at a time keeps arrival order

   An automation set to run one at a time, refused or queued, runs its event runs in the order the events arrived. An event run is never refused for an open run; it waits.

5. 05

   A failed event run alerts and is not replayed

   It is recorded with its cause like any run, and its owner is told as for a failed scheduled run. The platform does not run it again on its own, and the next event still runs.

6. 06

   The event stays in its table

   Whatever the automation does, the event is in the source’s table, so a run that failed or was skipped can be made good later by a run by hand or a scheduled sweep that reads the table.