규칙 테스트
이 규칙이 최근 메시지 중 무엇을 잡았을지 보여줍니다. 아무것도 바꾸지 않습니다.
본인 키로 워크스페이스에 실제 호출을 실행합니다.
POST /rules/{id}/test
이 규칙이 최근 메시지 중 무엇을 잡았을지 보여줍니다. 아무것도 바꾸지 않습니다.
예제
rules:read가 필요합니다. 드라이런은 메일함을 읽고 아무것도 쓰지 않으므로 rules:write 작업이 아닙니다. days는 기본 30이고 365까지, limit은 기본 50이고 200까지이며, threadIds는 기간 대신 지정한 스레드를 테스트합니다.
curl -X POST "$OE/rules/rul_7f3a1c94e05d3862c1f0a44b/test" -H "$AUTH" \ -H "Content-Type: application/json" \ -d '{ "days": 30, "limit": 50 }'{ "object": "rule_test", "ruleId": "rul_7f3a1c94e05d3862c1f0a44b", "scanned": 50, "matched": 3, "wouldApply": ["label:USER_RECEIPTS", "archive"], "messages": [ { "threadId": "thr_5d31c2a8…", "from": "[email protected]", "subject": "Your receipt", "receivedAt": "2026-08-28T10:00:00.000Z" } ], "warnings": [{ "code": "forward_unverified", "value": "[email protected]" }]}전달 경로에서 도는 바로 그 엔진이 이 답을 냅니다. 의도적으로 순수한(데이터베이스도 네트워크도 없는) 하나의 모듈이어서, 설정 화면과 드라이런과 SMTP 핸들러가 규칙 일치 여부를 두고 어긋날 수 없습니다. 두 번 작성된 미리보기는 한 질문에 대한 두 개의 답이고, 사람에게 보이는 쪽이 틀린 답입니다.
구조상 제한됩니다. 최대 1년 동안의 최대 200개 메시지입니다. 이것은 실행 시간 예산이 있는 Worker 안에서 돌며, 무제한 스캔은 도중에 죽어 아무것도 보여주지 못하는 요청입니다.
비활성 규칙도 테스트할 수 있습니다. 그게 핵심입니다. 쓰고, 테스트하고, 그다음 켜십시오.
warnings는 파싱은 되지만 의도대로 동작하지 않을 규칙이 드러나는 곳입니다. 아무도 확인하지 않은 전달 주소가 가장 자주 만나게 될 경우입니다. 경고가 테스트를 멈추는 일은 없습니다. 드라이런의 목적은 첫 문제에서 실패하는 것이 아니라 한 번에 찾은 것을 전부 보고하는 것입니다.
"내 메일함 전체에 실행"은 없다
POST /rules/{id}/run은 의도적으로 없으며, 앞으로도 없을 것입니다. 규칙을 메일함 전체에 소급 적용하는 것은 제한이 없고, 되돌릴 수 없으며, 실행 취소도 없습니다(10년치 메일에 대한 trash 액션은 두 번째 기회가 없는 한 번의 호출입니다). 게다가 그것이 써야 할 쓰기 경로는 저장된 스레드에 병합되므로, 정리하려다 건드린 모든 메시지를 받은편지함 맨 위로 올리는 부작용을 낳습니다.
이 엔드포인트는 그 요청의 정직한 절반입니다. 실제 질문인 "이것이 무엇을 했을까"에 답하고, 그다음 정말로 의도한 메시지는 PATCH /threads/{id}로 직접 정리하면 됩니다.