-- PR-26 (May 2026): PendingEscalation table for delayed notifications
-- =========================================================
-- Backs NotificationRule.escalationDelay (which has been a documented
-- stub since PR-C.1). When a rule with escalationDelay > 0 matches,
-- the dispatcher writes a row here instead of firing immediately;
-- the worker re-checks the trigger after the delay and dispatches
-- only if still firing.

-- ============================================================
-- UP
-- ============================================================

CREATE TABLE `PendingEscalation` (
  `id`           INT NOT NULL AUTO_INCREMENT,
  `ruleId`       INT NOT NULL,
  `eventKey`     VARCHAR(255) NOT NULL,
  `event`        VARCHAR(64)  NOT NULL,
  `payload`      TEXT         NOT NULL,
  `monitorId`    INT NULL,
  `incidentId`   INT NULL,
  `scheduledFor` DATETIME(3) NOT NULL,
  `createdAt`    DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
  PRIMARY KEY (`id`),
  KEY `PendingEscalation_scheduledFor_idx` (`scheduledFor`),
  KEY `PendingEscalation_monitorId_idx` (`monitorId`),
  KEY `PendingEscalation_incidentId_idx` (`incidentId`),
  KEY `PendingEscalation_ruleId_idx` (`ruleId`),
  CONSTRAINT `PendingEscalation_ruleId_fkey`
    FOREIGN KEY (`ruleId`) REFERENCES `NotificationRule` (`id`)
    ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

-- ============================================================
-- DOWN
-- ============================================================

DROP TABLE `PendingEscalation`;