GitHub user weiqingy added a comment to the discussion: [Feature] Per-Event-Type Configurable Log Levels for Event Log
Thanks @xintongsong ! 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! 2. Parsability of truncated content. Agreed. I'll update the design doc to reflect this. 3. Removing EventFilter. The existing ACCEPT_ALL / REJECT_ALL / byEventType functionality is fully covered by the log level equivalents (STANDARD, OFF, per-type levels). The only gap is custom `accept(Event, EventContext)` logic that filters by event content or context - but I don't think there are many use cases for this today. cc: @alnzng If there is no gap concern, I'll remove EventFilter. Let me know. 4. Validation. Good point that not all event types are known at initialization. I see two options: - Best-effort validation: At init, collect known event types from actionsByEvent keys (events listened by actions) plus the built-in framework types. This covers the common case. For configured types not in this set, log a warning to help catch typos. At runtime, the configured level still applies correctly - unconfigured types fall back through the hierarchy as designed. - Skip validation entirely: Since users may define custom events only known at runtime, strict upfront validation isn't possible. If a configured type string doesn't match anything, the system doesn't error - it simply has no effect until a matching event appears, at which point the hierarchy resolves normally. - 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. GitHub link: https://github.com/apache/flink-agents/discussions/552#discussioncomment-15978191 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
