Skip to content

Spike: revisit the throttle granularity of the dropped-event-field diagnostic #165

@OmarAlJarrah

Description

@OmarAlJarrah

Context

The diagnostic that flags a dropped field("event") colliding with the event(name) tag is throttled to once per ClientLogger instance (see #132). Two consequences:

  • Distinct call sites that make the same mistake on the same logger collapse to a single line.
  • Only the first observed event-name tag is recorded as the example; later collisions carrying a different tag are not shown.

To decide

Is once-per-logger the right granularity, or should it be:

  • once per (logger, call site) — so different mistakes are each surfaced once, or
  • once per (logger, event-name tag) — so each distinct tag's collision is reported once?

Any finer granularity needs a bounded key set so a hot loop emitting many distinct tags cannot grow the throttle state without limit. Designing that bound is the main work here.

Why a spike

The current choice deliberately favours "never flood DEBUG" over completeness. Whether the completeness loss matters in practice depends on real misuse patterns, so it is worth a short look before adopting a more complex throttle.

Metadata

Metadata

Assignees

No one assigned

    Labels

    SpikeTime-boxed investigation / design decision

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions