Spec defect: `content_not_contains` with `text: ""` is always false, contradicting example usage #6

New issue

Open

opened 2026-05-27 05:24:36 +00:00 by hurui200320 · 0 comments

hurui200320 commented

2026-05-27 05:24:36 +00:00

Member

Problem

§5.4 defines content_not_contains as:

True if the substring is NOT in the message content (stringified).

However, §5.3.2 uses this condition with text: "" in two separate examples as a way to "drop empty messages":

- type: filter
  params:
    condition:
      type: content_not_contains
      text: ""

By the definition, an empty string "" is always a substring of any string (including the empty string itself). Therefore content_not_contains with text: "" always evaluates to false and would drop all messages unconditionally — not just empty ones.

This is a logical error in either the condition semantics definition or in the examples (or both).

Impact on Library Implementation

An implementor following the §5.4 definition strictly would produce different behavior from what the §5.3.2 examples intend. The condition semantics and example usage are irreconcilable without a spec correction.

Decision Needed

One of the following:

Fix the semantics: Special-case text: "" in content_not_contains to mean "content length is zero" (i.e., drop the message if content is empty or whitespace-only).
Fix the examples: Replace text: "" with a more meaningful condition, such as type: always combined with a length check, or introduce a dedicated content_empty / content_not_empty condition type.
Add a new condition type: e.g., content_not_empty that is true when the message content has non-zero length.

References

§5.3.2 — filter operator examples (two occurrences of content_not_contains: text: "")
§5.4 — Conditions definition table
§18.12 — Stream with Aggregation, Filter, and Error Handling (uses the same pattern)

## Problem §5.4 defines `content_not_contains` as: > True if the substring is NOT in the message content (stringified). However, §5.3.2 uses this condition with `text: ""` in two separate examples as a way to "drop empty messages": ```yaml - type: filter params: condition: type: content_not_contains text: "" ``` By the definition, an empty string `""` is always a substring of any string (including the empty string itself). Therefore `content_not_contains` with `text: ""` always evaluates to **false** and would drop **all** messages unconditionally — not just empty ones. This is a logical error in either the condition semantics definition or in the examples (or both). ## Impact on Library Implementation An implementor following the §5.4 definition strictly would produce different behavior from what the §5.3.2 examples intend. The condition semantics and example usage are irreconcilable without a spec correction. ## Decision Needed One of the following: 1. **Fix the semantics**: Special-case `text: ""` in `content_not_contains` to mean "content length is zero" (i.e., drop the message if content is empty or whitespace-only). 2. **Fix the examples**: Replace `text: ""` with a more meaningful condition, such as `type: always` combined with a length check, or introduce a dedicated `content_empty` / `content_not_empty` condition type. 3. **Add a new condition type**: e.g., `content_not_empty` that is true when the message content has non-zero length. ## References - §5.3.2 — `filter` operator examples (two occurrences of `content_not_contains: text: ""`) - §5.4 — Conditions definition table - §18.12 — Stream with Aggregation, Filter, and Error Handling (uses the same pattern)

Rows
Columns

Spec defect: content_not_contains with text: "" is always false, contradicting example usage #6

Problem

Impact on Library Implementation

Decision Needed

References

Spec defect: `content_not_contains` with `text: ""` is always false, contradicting example usage #6