Skip to content

x/telemetry/counter/countertest: improve ergonomics of countertest.Read #71590

Open
@findleyr

Description

@findleyr

While investigating a frequent gopls flake (#68659), I encountered several API problems with the countertest package that make it hard (or really impossible) to use correctly.

I believe the sequence of events that leads to the flake in question are:

  1. TestMain calls countertest.Open, because it must be called once during program execution.
  2. The test setup first performs an initial increment of counter values, since we must inc before the first Read as ReadCounter(counter.New("unknownCounter")) returns an error rather than succeeding and returning 0.
  3. ReadCounter calls rotate1 internally. I'm not sure why. Since TestMain may have occurred ~minutes ago, it's quite likely that the day has actually changed in the meantime, and so the file rotation invalidates the previous counters.

IMO, all three of these are indicative of an API problem:

  1. We should probably be able to call countertest.Open inside each test (albeit not in parallel), to increase test isolation.
  2. ReadCounter(counter.New("unknownCounter")) should return the zero value.
  3. ReadCounter should probably not call rotate1, but even if it does, countertest should not be subject to day shifts. We should either stop time, or let the countertest user control the progress of time. Otherwise, no test can assert on the output of Read.

At the very least, we should fix (3), but it would be good to fix (1) and (2) as well.

Metadata

Metadata

Assignees

No one assigned

    Labels

    FeatureRequestIssues asking for a new feature that does not need a proposal.NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.telemetryx/telemetry issues

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions