doubly escape periods in counter names so we dont create invalid json#3000
doubly escape periods in counter names so we dont create invalid json#3000bbeaudreault wants to merge 1 commit intovitessio:masterfrom
Conversation
|
By the way, I found the original escaping change to be unnecessary, though I can work around it once the json is valid. Since we know the format of the keys, we could still properly split the keys accounting for potential periods. It was a bit involved, but worked: # for maps where one of the keys is the username, the username may have periods in it.
# Account for that in how we parse split on periods below.
idx = tag_list.index('user')
if idx == 0:
# no username, just split from right
tag_data = name.rsplit(key_split_char, len(tag_list) - 1)
elif idx == len(tag_list) - 1:
# username is the last item in the list, split from left
tag_data = name.split(key_split_char, len(tag_list) - 1)
else:
# limited split from left, up to where the username is
lparts = name.split(key_split_char, idx)
# limited split of remainder from right, backwards to username
rparts = lparts[idx].rsplit(key_split_char, len(tag_list) - idx - idx)
# contains everything up to but not including username
tag_data = lparts[:idx]
# add rparts on, the first item will be the username with dots in it
tag_data += rparts |
|
@bbeaudreault Congrats on pull request #3000 ! :) Sugu got #1000 and I #2000 back then :D |
|
Woohoo! |
|
Another bonus is that this year we hit 1000 PRs a month early! |
|
@sougou how long should we give @nerdatmath to respond here before we just merge this? As far as I can tell the original PR broke the /debug/vars for all existing users who try to parse it as json, in at least python and go. So this may break any specific parsing he's added, but will fix everyone else. |
|
I want to see if the previous change can be rolled back in favor of an internal fix. I'll try to catch @nerdatmath when he's online to chat about it. |
|
Sounds good, thanks |
|
The problem's not in my change, although my change revealed it. The problem is in the String method of Counters. Compare it to the String method of expvar.Map, and you'll see that where they use %q (which does the escaping required to generate valid JSON), we use "%v", which is equivalent to "%s" in this case because keys are always strings, and %s doesn't do any escaping. #3005 sent to fix Counters.String. |
|
This was fixed more correctly by #3005 |
This fixes an issue created by #2992. This broke our automation and monitoring which relies on the json response of /debug/vars being proper json.
cc @nerdatmath @sougou