# ActivateNotificationChannel

## Permission Scope

channelRegistry

## Overview

activateNotificationChannel flips the `enabled` flag on an existing NotificationChannel registry row to `true`, allowing the dispatcher to begin (or resume) targeting that channel for new events. The command is the explicit re-enable counterpart to `deactivateNotificationChannel` and is idempotent: calling it on an already-enabled channel returns success without mutating state. Re-enabling does **not** replay events that were skipped while the kill-switch was off; the next dispatch is the first that the channel sees again.

## Business Rules

- `channelId` is required to identify the target row
- A NotificationChannel row must exist for the supplied `channelId`
- The command is idempotent — invoking it on a row whose `enabled` is already `true` is a successful no-op
- Past Notifications are not retroactively created or replayed; only future dispatches are affected

## Process Flow

```mermaid
flowchart TD
    A[Receive activate channel request] --> B{NotificationChannel exists?}
    B -->|No| C[Return CHANNEL_NOT_FOUND]
    B -->|Yes| D{enabled is already true?}
    D -->|Yes| E[Idempotent no-op, return current row]
    D -->|No| F[Set enabled = true]
    F --> G[Return updated row]
```

## External Dependencies

- None (operates on module-owned NotificationChannel registry only)

## Error Scenarios

- **CHANNEL_NOT_FOUND**: No NotificationChannel row matches the supplied channelId

## Test Cases

- flips enabled from false to true on an existing NotificationChannel row
- returns the existing row unchanged when enabled is already true (idempotent)
- returns CHANNEL_NOT_FOUND when the channelId does not exist
- the next dispatch after activation includes the channel in fan-out
- activation does not retroactively persist Notifications for events emitted while the channel was disabled