규칙 실행 목록
규칙이 실제로 한 일을, 메시지당 규칙당 한 행으로.
본인 키로 워크스페이스에 실제 호출을 실행합니다.
GET /rules/runs
규칙이 실제로 한 일을, 메시지당 규칙당 한 행으로.
예제
rules:read가 필요합니다. 최신순입니다. ruleId는 하나의 규칙으로 좁히고, threadId는 "이 메시지가 왜 여기 들어왔는가"에 답합니다.
curl "$OE/rules/runs?threadId=thr_5d31c2a8…&limit=25" -H "$AUTH"{ "object": "list", "data": [ { "object": "rule_run", "id": "rrun_9c1f0a4b7e05d3862c1f0a44", "ruleId": "rul_7f3a1c94e05d3862c1f0a44b", "ruleName": "Receipts to their own label", "threadId": "thr_5d31c2a8…", "messageId": "msg_c5f21cc6…", "sender": "[email protected]", "subject": "Your receipt", "actions": ["label", "archive"], "failures": [], "createdAt": "2026-08-29T11:04:12.000Z" } ], "hasMore": false, "nextCursor": null}actions에는 적용된 것이, failures에는 거부된 것이 type: reason 형태로 담깁니다. 하나의 주석 달린 목록이 아니라 별개의 목록인 이유는 "규칙이 보관했다"와 "규칙이 보관하려 했다"가 서로 다른 사실이고, 둘을 뒤섞은 로그는 어느 질문에도 답할 수 없기 때문입니다. 여기 있는 것은 액션 타입뿐입니다. 값은 규칙에 있고, 테스트의 wouldApply가 그것을 낱낱이 적는 유일한 곳입니다.
억제된 자동 회신은 여기에 reply: auto-reply suppressed because the message carries List-Id 형태로 나타나며, 여기가 유일한 자리입니다. 일부러 나가지 않은 회신을 드러내는 곳은 달리 없고, 그러지 않으면 "왜 내 부재중 응답이 저기엔 답하지 않았지"에 답할 방법이 없습니다.
ruleName은 읽을 때 조인하지 않고 행에 저장되므로, 규칙 이름이 바뀌거나 삭제된 뒤에도 로그가 제대로 읽힙니다. 더 이상 존재하지 않는 규칙을 가리키는 행은 끊어진 참조가 아니라 정상적인 경우입니다.
발신자당 하루 한 번이라는 자동 회신 제한은 같은 테이블의 클레임 행으로 강제되며, 이 로그는 그것을 반환하지 않습니다. 하루 안에 같은 발신자에게 두 번째 부재중 응답이 나가지 않는 이유입니다.