A hook call used to record only how it was taken; its run's answer went to the chat alone and was lost to the call once the job was pruned. Now `bot_hook_events` keeps `response`, `response_message_id` and `responded_at`, written on every call a run took in when that run ends (completed, failed, lost, stopped or cancelled) by `recordHookCallResponse` in the job helpers, and calls turn done or failed. The Calls view searches what calls sent and what runs answered, filters by status and pages; Show all loads one call whole. Bots get `search_hook_calls` and `read_hook_call` for their own hooks (never in a hook call's own run), with payloads always marked as outside data. Calls are kept for the app setting `hook_events_keep_days` (Settings > General, default now 30 days). The caller still only gets 202 Queued. Co-Authored-By: Claude Opus 5.5 <[email protected]>
26 lines
920 B
TypeScript
26 lines
920 B
TypeScript
type Params = {
|
|
hook_id: number;
|
|
/**
|
|
* The run that ended.
|
|
*/
|
|
job_id: number;
|
|
status: "done" | "failed";
|
|
response: string;
|
|
message_id?: number | null;
|
|
now: number;
|
|
};
|
|
|
|
/**
|
|
* Writes a run's end onto every call it took in (the one that queued it
|
|
* and any merged into it): answered or failed, with its response. Only
|
|
* calls still waiting on it change, so a call already answered never is
|
|
* written over.
|
|
*/
|
|
export default function recordHookCallResponseSql({ hook_id, job_id, status, response, message_id, now }: Params) {
|
|
return {
|
|
sql: `UPDATE bot_hook_events SET status = ?, response = ?, response_message_id = ?, responded_at = ?, updated_at = ?
|
|
WHERE hook_id = ? AND job_id = ? AND status IN ('queued', 'merged') RETURNING id`,
|
|
values: [status, response, message_id ?? null, now, now, hook_id, job_id] as (string | number | null)[],
|
|
};
|
|
}
|