`drop_on_error` default value inconsistency with `drop_on_abort`

Vector version: 0.58.0

Severity: Major (production data loss risk)

Description:

There is an inconsistency in default values for drop_on_abort vs drop_on_error:

Source code (confirmed): src/transforms/remap.rs:125:

#[serde(default = "crate::serde::default_false")]
pub drop_on_error: bool,

src/transforms/remap.rs:142:

#[serde(default = "crate::serde::default_true")]
pub drop_on_abort: bool,

• drop_on_abort: default = true (drop aborted events)
• drop_on_error: default = false (pass through fallible errors)

For to_int!(), the fallible assignment becomes zero (default for Int) on parse failure rather than dropping the event. Operators have no warning that data was silently lost.

Reproduction:

If a VRL program uses fallible assignment without checking error:

.parsed_num, .err = to_int(.message)

When message = "garbage":

• parsed_num becomes 0 silently
• err is populated with error text (visible only if operator inspects .err)
• Event is still passed downstream with parsed_num = 0

Combined with skip_unknown_fields: true on the CH sink, operators may not realize the upstream data quality issue for hours.

Expected:

drop_on_error should default to true for production safety, mirroring drop_on_abort. Operators who explicitly want silent default values can still set drop_on_error: false.

Suggested fix:

#[serde(default = "crate::serde::default_true")]  // change to default_true
pub drop_on_error: bool,

Workaround:

Set drop_on_error: true + reroute_dropped: true explicitly in remap configs.

Impact:

Production deployments using Vector defaults lose data on cast errors without explicit warning.

Confirmed in source: src/transforms/remap.rs:125, 142 (Vector 0.58.0)