vectordotdev/vector · error

event will be set

Error message

event will be set

What it means

remap clones the incoming event only when `(program fallible && forward_on_error) || (program abortable && forward_on_abort)` (src/transforms/remap.rs:598). On failure it does `original_event.expect("event will be set")` at the `!drop` branch. The panic means the VRL runner returned `Terminate::Error` for a program compiled as infallible (or `Terminate::Abort` for a non-abortable program) while the event must be forwarded — a contract violation between the VRL runner and the compiled program metadata, not a configuration error.

Source

Thrown at src/transforms/remap.rs:649

                            emit!(RemapMappingAbort {
                                event_dropped: self.drop_on_abort,
                            });
                        }
                        ("abort", error, self.drop_on_abort)
                    }
                    Terminate::Error(error) => {
                        if !self.reroute_dropped {
                            emit!(RemapMappingError {
                                error: error.to_string(),
                                event_dropped: self.drop_on_error,
                            });
                        }
                        ("error", error, self.drop_on_error)
                    }
                };

                if !drop {
                    let event = original_event.expect("event will be set");

                    push_default(event, output);
                } else if self.reroute_dropped {
                    let mut event = original_event.expect("event will be set");

                    self.annotate_dropped(&mut event, reason, error);
                    push_dropped(event, output);
                }
            }
        }
    }
}

#[inline]
fn push_default(event: Event, output: &mut TransformOutputsBuf) {
    output.push(None, event)
}

View on GitHub (pinned to 99894c8d88)

Solutions

1. Upgrade Vector to a release fixing the VRL fallibility/runner mismatch; search the GitHub tracker for "event will be set" reports
2. Workaround: set `drop_on_error = true` (and `drop_on_abort = true`) without `reroute_dropped`, so neither expect branch runs
3. Reproduce with `vector vrl` using the program plus a sample event and file an issue with both
4. If embedding: replace the expect with a fallback that pushes the mutated target event and logs the invariant break

Example fix

# before
[transforms.process]
type = "remap"
source = "parsed"
drop_on_error = false  # default; expect branch reachable on runner invariant break
# after
[transforms.process]
type = "remap"
source = "parsed"
drop_on_error = true
drop_on_abort = true

# check your Vector version against the issue tracker before relying on
# infallible-compiled programs that touch fallible operations
vector --version

When it happens

Trigger: A VRL program whose compile-time fallibility analysis said "cannot fail" but which raises a runtime error (runner bug, e.g. after VRL compiler changes), while `drop_on_error` is false (the default) so the original event is needed for forwarding.

Common situations: Specific Vector/VRL versions where fallibility analysis disagrees with runtime behavior — programs with coerced/assumed-infallible operations that still error at runtime; reports typically include a program that 'cannot fail' yet errors.

Related errors

• Data poisoned
• MessageStream never calls Ready(None)
• MessageStream never returns Ready(None)
• Messages are consumed in dedicated tasks for each partition.
• Indexer acknowledgements channel must allow at least one pen

AI-assisted analysis of vectordotdev/vector@99894c8d88 (2026-08-20). Data as JSON: /api/errors/780b8800b693c14c. Report an issue: GitHub.