ThearchyHelios
1ad087c387
- evidence.md「复核套件」：开头讲三项共用的只读核查 agent 和「设置 → 偏好设置 → 核查」，再按代码模块文档逐项写解决什么、怎么用、结果、局限；可验证报告的细节并进「导出」一节（只证明内部一致、封存后追加的单列、遮罩、何时能导出），复核套件里链过去 - evidence.md 新增「查询区间里没有数据」：整列是 0 时现查表里实际的日期范围，口径卡标「区间内无数据」、出具降档、写作提醒、问数据按复核重来、助手自查、宁可漏报；data-catalog.md 的数据剖析一节链过去 - schedules.md：访问密钥到期提醒写明个人密钥发本人的个人渠道、服务账号的密钥发全局渠道，以及消息里有什么；定时运行结束后的自动对比链到运行对比 - README 两版：功能列表加复核套件一条，文档索引里证据与出具一行补上新加的两节 scripts/check-docs.py：英文文档中文字符 0 处，相对链接 383 条全通，中英文档 18 对标题层级一致
4.7 KiB
English | Simplified Chinese
Schedules, Event Triggers, and Notifications
This page covers how to run workflows automatically on a schedule or when an event happens, and how results and reminders reach people. It is for builders and admins. The user interface is currently available in Simplified Chinese only.
Schedules
A schedule starts formal runs on time, and the origin of each run is recorded as the schedule.
- The target can be a workflow, a data source (that is, scheduled maintenance of the data source; see Data Catalog), or a test suite (that is, a scheduled evaluation; see Regression evaluation).
- App views prefer to bind to existing schedules. A dashboard reads the schedule's latest sealed formal run, and its stamp names the schedule and the run number.
- When a run is rejected by a person, the schedule pushes "Not issued (rejected)".
- When a run finishes successfully and is sealed, it is compared once automatically with the same schedule's last successful run, and the trigger history offers Compare With Previous Run (see Run comparison).
- Schedules that target a data source or a test suite don't accept webhooks (they return 422); their notifications go through channel subscriptions under Settings → Notifications.
- For run concurrency, schedules belong to the scheduled class (see Run concurrency).
- The scheduler loop ticks every
AGENTLAB_SCHEDULER_TICK_S, 15 seconds by default.
Event triggers
A schedule can choose Event trigger and run when one of these events happens:
- an uploaded spreadsheet gets a new period;
- a formal run of an upstream workflow finishes successfully;
- a data source has changes that need action.
Rules:
- Events are recorded where they happen, and the scheduler loop starts runs after debouncing; each period is debounced separately.
- Downstream input templates read the event content with
{{ event.* }}. - Saving checks that chains don't form a cycle; at run time, chains are limited to 5 levels.
- Runs that passed through a rejection, and runs that come from app backfills, don't trigger downstream by default; you can tick a box to let them.
- This follows the
AGENTLAB_SCHEDULERswitch: when the switch is off, events are kept but not dispatched.
Notifications
Channels
Notifications go to channels, which are either global or personal; subscribe to them under Settings → Notifications. Webhooks can be delivered too.
Tasks, notifications, and webhooks state plainly where a rejection went ("Rejected, routed to X", "This path ends here").
An admin configures SMTP under Settings → Notifications → Mail Service; the password is stored encrypted. After that, email channels can be created.
- Email only confirms handoff to the mail server; bounces aren't tracked.
Subscribable events
| Event | Sent to | Notes |
|---|---|---|
| "Instance finished" | Subscribed channels | Includes runs rejected by a person |
| "Scheduled evaluation regressed" | Subscribed channels | Only the test suite name, pass count, number of regressed questions, and a link |
| "Data source has changes to handle" | Global channels | Only the source name, the count, and a link; no table names, column names, or values |
| "Caliber version bumped, answer numbers changed" | Global channels and the answer owner's personal channels | No numbers; ledger.recall is pushed at the same time |
| Daily task digest | Personal channels subscribed to it | Sent at notify.digest_at, default 09:00 (server time zone) |
| Access key expiry reminder | Personal keys go to the owner's personal channels subscribed to it; service account keys go to global channels subscribed to it | Once 7 days and once 1 day before expiry; only the key name, its prefix, the owner, the expiry time, and a link to rotate it, never the key itself |
The daily digest and access key reminders are sent only when login is on.
The scheduler switch
When AGENTLAB_SCHEDULER is turned off (set to 0):
- process time limits aren't checked: no reminders, no escalation, no automatic verification;
- events are kept but not dispatched;
- the retroactive caliber matching of the last 7 days at startup doesn't run, and neither do the automatic caliber recall batches after publishing or their continuation at startup.
In a multi-process deployment, claiming schedules, dispatching events, delivering webhooks, process time limits and verification, and the daily digest all happen only in the process that is the scheduler leader (see Scheduler leader).