[Safety] Enforce a configurable maximum for synchronous Campaign sends #79

New Issue

zemion · 2026-07-21T19:46:32+02:00

zemion commented

2026-07-21 19:46:32 +02:00

Problem / User Need

A synchronous Campaign send can hold a request open and consume application capacity for an unbounded recipient count. The limit must be enforced by the backend rather than presented only as UI guidance.

Acceptance Criteria

A deployment/tenant-effective policy exposes a bounded maximum recipient-job count for synchronous send mode with a documented safe default.
Validation and the final send command reject a synchronous run above the effective maximum before any external effect starts and direct the user to asynchronous queueing.
The count uses the exact built/eligible execution set, not an editable draft estimate.
The WebUI shows the effective limit and disables synchronous send when the built run exceeds it, while asynchronous send remains available when configured and permitted.
Policy source, rejection, and selected mode are auditable without recording recipient data or transport secrets.
Boundary, race/rebuild, zero-recipient, permission, and module-configuration tests cover both modes.
The Campaign handbook and adaptive Docs topic state the effective configured limit.

#62 owns mode wording and progress behavior.
This issue owns the hard safety limit and policy contract.

## Problem / User Need A synchronous Campaign send can hold a request open and consume application capacity for an unbounded recipient count. The limit must be enforced by the backend rather than presented only as UI guidance. ## Acceptance Criteria - A deployment/tenant-effective policy exposes a bounded maximum recipient-job count for synchronous send mode with a documented safe default. - Validation and the final send command reject a synchronous run above the effective maximum before any external effect starts and direct the user to asynchronous queueing. - The count uses the exact built/eligible execution set, not an editable draft estimate. - The WebUI shows the effective limit and disables synchronous send when the built run exceeds it, while asynchronous send remains available when configured and permitted. - Policy source, rejection, and selected mode are auditable without recording recipient data or transport secrets. - Boundary, race/rebuild, zero-recipient, permission, and module-configuration tests cover both modes. - The Campaign handbook and adaptive Docs topic state the effective configured limit. ## Related Work - #62 owns mode wording and progress behavior. - This issue owns the hard safety limit and policy contract.

zemion commented

2026-07-22 09:47:29 +02:00

Codex State: done

Summary

Synchronous delivery now has a mandatory deployment ceiling that tenants may only lower, pre-effect validation, and a second post-queue concurrency check.
Limit/configuration failures are fail-closed; ordinary results and audit evidence omit provider diagnostics and recipient addresses.

Verification

Campaign backend: 180 passed, 16 subtests passed
Bounded-delivery and response-security regressions (pass)

## Codex State: done ### Summary - Synchronous delivery now has a mandatory deployment ceiling that tenants may only lower, pre-effect validation, and a second post-queue concurrency check. - Limit/configuration failures are fail-closed; ordinary results and audit evidence omit provider diagnostics and recipient addresses. ### Verification - `Campaign backend: 180 passed, 16 subtests passed` - `Bounded-delivery and response-security regressions (pass)`

zemion closed this issue

2026-07-22 09:47:30 +02:00

zemion referenced this issue

2026-07-22 09:48:30 +02:00

[Task] Audit and migrate Campaign interfaces to the product-wide pattern language #74

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-campaign#79