Trigger and Accumulation Mode

In stream processing, a trigger decides when a window’s aggregate is emitted, and the accumulation mode decides what the next emission means relative to the previous one. Apache Beam states both precisely: triggers “determine when to emit the aggregated results of each window (referred to as a pane),” and “the accumulation mode determines whether the system accumulates the window panes as the trigger fires, or discards them.” Descriptions follow that guide, checked in September 2026.

This is a different idea from an Airflow trigger rule, which decides whether a downstream task may run given its upstream task states. Here the question is not whether work starts but when a result is published.

Why a window emits more than once

A window over event time cannot be known to be complete; it can only be estimated as complete by a watermark. Waiting for that estimate gives one result per window and the longest delay. Emitting before it gives an earlier answer that may change. A trigger is how that choice is expressed, and Beam provides both event-time triggers, which fire relative to the watermark, and processing-time triggers, which fire on wall-clock progress regardless of what has arrived.

The default is the conservative one, and worth knowing before assuming a platform is unresponsive: with the default windowing configuration and default trigger, Beam “outputs the aggregated result when it estimates all data has arrived, and discards all subsequent data for that window.” One emission, nothing late. Anything more responsive is something you asked for.

The two modes, with the same firings

Beam’s worked example uses ten-minute windows and a trigger that fires every time three elements arrive. In accumulating mode, the successive firings for one key emit [5, 8, 3], then [5, 8, 3, 15, 19, 23], then [5, 8, 3, 15, 19, 23, 9, 13, 10] — each pane contains everything seen so far. In discarding mode, each firing emits only what arrived since the last one.

Neither mode is more correct. What makes one wrong is a mismatch with what the destination does, and the table above states each pairing in its safe form rather than its convenient one. An upsert keyed by window, or a dashboard reading the latest row, suits accumulating panes — with the qualification that “latest” has to be decided by a pane version rather than by arrival, since a delayed earlier pane would otherwise overwrite a newer one. An append-only table that sums its rows suits discarding panes, provided the aggregate is one that can be added and each pane is counted once.

Two cases fall outside both defaults and are the ones that go wrong quietly. An aggregate that is not additive — an average, a distinct count, a ratio — cannot be assembled by adding discarding panes at all; what has to be combined is the partial state (the sum and the count, the set or sketch), not the emitted number. And an accumulating pane written by append leaves every partial figure in the table, so readers need the window and a pane identifier to pick the current one. The pairing is the design decision; the mode by itself is only half of it.

What consumers have to be told

Early emission means publishing numbers that will change, and that is a communication problem rather than a technical one. Two habits cover it. Mark a value as provisional where it is read, so nobody quotes a partial window as a final figure. And say when it stops changing — the point after which the number is fixed, which is a business decision rather than a property of the engine.

Two conditions decide whether either mode is usable by the consumer you have. Discarding output has to be combinable by whatever the consumer does with it, and that is addition only for sums and counts — averages, distinct counts and ratios cannot be added, so emit sum and count, a mergeable sketch, or numerator and denominator instead. Accumulating output has to let a reader identify the latest emission. An upsert keyed by window does that when it compares versions — without a comparison, a late earlier pane can overwrite a newer one. An append works when each row carries the window and a pane identifier and readers pick the latest. Appending bare values with no such marker is the case that fails. Note also that “latest known” is not “final” while lateness is still allowed.

Where a figure changes after consumers have already acted on it, the change deserves the treatment any corrected period gets: announced as a restatement rather than applied quietly. How triggers, accumulation, windows, and lateness settings combine into a result someone can rely on is worked through in Stream Processing Semantics; the grouping they operate on is covered in stream windowing.

Reference: Apache Beam Programming Guide, Triggers and window accumulation modes.