envoyproxy/envoy

stats: inconsistent handling of multiple consecutive dots in stat-names produced via join vs direct encoding

Open

#10,008 opened on Feb 11, 2020

View on GitHub
 (1 comment) (0 reactions) (1 assignee)C++ (5,373 forks)batch import
area/statshelp wanted

Repository metrics

Stars
 (27,997 stars)
PR merge metrics
 (Avg merge 8d) (378 merged PRs in 30d)

Description

You can create a multi-segment stat-name by directly encoding it into the table, or by joining multiple existing stat names.

When you encode directly, you can wind up with multiple consecutive dots. When you construct by joining, you can't. The testcase in this commit illustrates the problem:

https://github.com/jmarantz/envoy/commit/6e7367c522c2fb5e77bb1d59cb54817e039bd9c3

TEST_P(StatNameTest, TestIgnoreTrailingDots) {
  EXPECT_EQ("foo.bar", encodeDecode("foo.bar."));
  EXPECT_EQ("foo.bar", encodeDecode("foo.bar..."));
  EXPECT_EQ("foo..bar", encodeDecode("foo..bar"));
  EXPECT_EQ("foo...bar", encodeDecode("foo...bar"));

  StatNamePool pool(*table_);
  SymbolTable::StoragePtr joined = table_->join({makeStat("a"), makeStat(""), makeStat("b")});
  EXPECT_EQ("a..b", table_->toString(StatName(joined.get())));   // FAILS, will be "a.b".

  EXPECT_EQ("", encodeDecode("."));
  EXPECT_EQ("", encodeDecode(".."));
}

Contributor guide