GitHub user xintongsong added a comment to the discussion: [Feature] Per-Event-Type Configurable Log Levels for Event Log
> 1. max-length and truncation. Good question. My thought was that max-length > is the sole user-facing config - the total serialized size target. The > per-field truncation strategies (string shortening, array trimming, depth > collapsing) are the implementation mechanisms for achieving that target, not > independent knobs. This keeps the model simple: one number controls the > output size. An alternative is to drop max-length and rely solely on per-field thresholds (max string length, max array size, max nesting depth) - and potentially expose those as individual configs. The trade-off is simplicity (one knob) vs granularity (multiple knobs). Feedback welcome! I'm not suggesting using per-field thresholds for user-facing knobs. Actually, my opinion is either to have one knob, or zero. My question was, if we have `max-length` as the only knob, how do we achieve this target size? Are the internal per-field thresholds calculated from the `max-length`? If true, how exactly are they calculated? If not, which means the thresholds are static, then how does different values of `max-length` affect the final size at all? > I'm leaning toward option 2 (skip validation) for simplicity. The hierarchy > fallback is safe - a misconfigured type name silently inherits from its > parent, and events still get logged. This matches how other logging > frameworks like Log4j handle unknown logger names. +1 GitHub link: https://github.com/apache/flink-agents/discussions/552#discussioncomment-15978797 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
