Context
PR #52 introduced the FanOutConsumer dispatcher pattern — a single TaskEventsTable stream consumer that routes events to channel-specific subscribers. The intent is to keep the stream-consumer count at 1 regardless of how many channels the platform supports, and to centralise the channel-filter logic so each subscriber doesn't reimplement it.
PR #42 shipped SlackNotifyFn as a direct TaskEventsTable stream consumer — written before #52 landed. It was not migrated onto the dispatcher when #52 merged.
The platform currently sits at 2 concurrent readers per shard on TaskEventsTable (SlackNotifyFn + FanOutConsumer). Per the DynamoDB Streams docs, "no more than two processes at most should be reading from the same stream's shard at the same time" — exceeding this causes throttling. It's an architectural constraint, not a raisable service quota.
The problem
Proposed shape
- Add a
SlackNotify subscriber under FanOutConsumer using the same subscription interface as the GitHub edit-in-place subscriber.
- Remove the direct DynamoDB Streams event-source mapping from
SlackNotifyFn.
- Fold the Slack-specific channel filter into the dispatcher's routing so the subscriber receives pre-filtered events.
- Preserve existing behaviour — threaded notifications, emoji reactions, cancel button — bit-for-bit; regression-test via the existing
slack-notify.test.ts.
After this lands:
TaskEventsTable concurrent shard readers: 1 (FanOutConsumer only).- New channels can subscribe to the dispatcher without touching the stream config.
- The Slack notifier stops reimplementing the channel-source filter.
References
Context
PR #52 introduced the
FanOutConsumerdispatcher pattern — a singleTaskEventsTablestream consumer that routes events to channel-specific subscribers. The intent is to keep the stream-consumer count at 1 regardless of how many channels the platform supports, and to centralise the channel-filter logic so each subscriber doesn't reimplement it.PR #42 shipped
SlackNotifyFnas a directTaskEventsTablestream consumer — written before #52 landed. It was not migrated onto the dispatcher when #52 merged.The platform currently sits at 2 concurrent readers per shard on
TaskEventsTable(SlackNotifyFn+FanOutConsumer). Per the DynamoDB Streams docs, "no more than two processes at most should be reading from the same stream's shard at the same time" — exceeding this causes throttling. It's an architectural constraint, not a raisable service quota.The problem
SlackNotifyFnoff the stream — there is no "raise a limit" path here.SlackNotifyFnfilters events inline rather than subscribing to the dispatcher'schannelSource === 'slack'fanout.Proposed shape
SlackNotifysubscriber underFanOutConsumerusing the same subscription interface as the GitHub edit-in-place subscriber.SlackNotifyFn.slack-notify.test.ts.After this lands:
TaskEventsTableconcurrent shard readers: 1 (FanOutConsumer only).References