Confirmed behavior needing an explicit delivery contract
Reviewed master at 886c36d8ebe861aa987059a1744d45b78797baae (v4.7.0). Enhancement / behavior decision, not a claimed confirmed default-policy bug.
Two verified ambiguities make webhook automation difficult to reason about:
- Scheduled outbound webhooks accept any HTTP response when
expected_status_codes is omitted. A fake 503 response returns normally and is recorded as successful execution. An explicit status list works. The reviewed contract does not establish whether omission intentionally means “any response,” so changing it silently would be unjustified.
- Inbound webhook processing logs and swallows trigger-callback failures; notification delivery determines HTTP acknowledgment. Trigger failure plus successful notification returns 200; successful triggering followed by failed notification can return 500 after an effect already ran. Notification delivery and schedule execution are different outcomes.
Mocked handler/scheduler reproductions confirmed these behaviors without network, credentials or live actions. A sender retrying a 500 may repeat trigger effects; HTTP itself does not provide exactly-once delivery and this issue does not claim otherwise.
Proposed improvement / acceptance criteria
- Document and expose separate transport/HTTP response, accepted trigger execution, and channel-notification outcomes.
- Make omitted outbound status expectations explicit in the UI; preserve existing schedules unless an approved migration changes their semantics.
- Decide acknowledgment policy for partial inbound success before changing status codes.
- Where source event IDs exist, consider durable event identity to prevent accidental repeat side effects while preserving intentionally distinct events. Do not indiscriminately deduplicate identical payloads.
- Test callback failure, notification failure after trigger success, retry/redelivery and explicit accepted HTTP error codes.
- Keep internal/loopback destination support and existing admin authority unchanged. No new destination restrictions.
This issue makes the observed behavior and decision visible without dressing an unresolved product choice up as a proven defect. No code was changed.
Confirmed behavior needing an explicit delivery contract
Reviewed
masterat886c36d8ebe861aa987059a1744d45b78797baae(v4.7.0). Enhancement / behavior decision, not a claimed confirmed default-policy bug.Two verified ambiguities make webhook automation difficult to reason about:
expected_status_codesis omitted. A fake 503 response returns normally and is recorded as successful execution. An explicit status list works. The reviewed contract does not establish whether omission intentionally means “any response,” so changing it silently would be unjustified.Mocked handler/scheduler reproductions confirmed these behaviors without network, credentials or live actions. A sender retrying a 500 may repeat trigger effects; HTTP itself does not provide exactly-once delivery and this issue does not claim otherwise.
Proposed improvement / acceptance criteria
This issue makes the observed behavior and decision visible without dressing an unresolved product choice up as a proven defect. No code was changed.