Wypisz uruchomienia reguł
Co twoje reguły faktycznie zrobiły, jeden wiersz na regułę na wiadomość.
Uruchamia prawdziwe wywołanie na twojej przestrzeni roboczej, twoim własnym kluczem.
GET /rules/runs
Co twoje reguły faktycznie zrobiły, jeden wiersz na regułę na wiadomość.
Przykład
Wymaga rules:read. Od najnowszych. ruleId zawęża do jednej reguły, a threadId odpowiada na „dlaczego ta wiadomość tu wylądowała”.
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 zawiera to, co ZASTOSOWANO, a failures to, czego odmówiono, jako type: reason. To osobne listy, a nie jedna z adnotacjami, bo „reguła to zarchiwizowała” i „reguła próbowała to zarchiwizować” to różne fakty, a log, który je zlewa, nie odpowie na żadne z tych pytań. To gołe typy akcji. Wartości żyją na regule, a wouldApply w teście to jedyne miejsce, gdzie są wypisane.
Stłumiona autoodpowiedź pojawia się tutaj, jako reply: auto-reply suppressed because the message carries List-Id, i tylko tutaj. Nic innego nie pokazuje odpowiedzi, która celowo nie wyszła, a „dlaczego mój autoresponder na to nie odpowiedział” nie ma poza tym odpowiedzi.
ruleName jest zapisywane w wierszu, a nie dołączane złączeniem przy odczycie, więc log czyta się poprawnie także po zmianie nazwy reguły lub jej usunięciu. Wiersz wskazujący regułę, która już nie istnieje, to przypadek normalny, a nie wisząca referencja.
Limit jednej autoodpowiedzi na nadawcę na dobę jest egzekwowany wierszem roszczenia w tej samej tabeli, którego ten log nie zwraca: to przez niego druga wiadomość o nieobecności do tego samego nadawcy w ciągu doby nigdy nie wychodzi.