envoyproxy/envoy
Voir sur GitHubstats: inconsistent handling of multiple consecutive dots in stat-names produced via join vs direct encoding
Open
#10 008 ouverte le 11 févr. 2020
area/statshelp wanted
Métriques du dépôt
- Stars
- (27 997 stars)
- Métriques de merge PR
- (Merge moyen 8j) (378 PRs mergées en 30 j)
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(".."));
}