Closed Bug 940361 Opened 11 years ago Closed 10 years ago

response counts for a locale in sidebar change when you select the locale

Categories

(Input Graveyard :: Dashboard, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: willkg, Assigned: willkg)

References

Details

(Whiteboard: u=user c=dashboard p=1 s=input.2014q4)

The summary is rubbish, but the gist of it is this:

1. go to https://input.mozilla.org/
2. look at the locale section of the sidebar on the left
3. for each locale look at the response count for that locale, then select the locale and then look a the response count again

For most of them, the two numbers will be the same. However, for some it's different.

For example, right now if I look at Spanish, the general number is 153, but if I select it, then I see 235. Further, the total number of responses in the upper right hand corner also says 235. All the other locales work fine.

Issue was discovered while writing tests. Comments here:

https://github.com/mozilla/input-tests/pull/156#issuecomment-28788870
Tossing this in the 2013q4 sprint to look into.
Whiteboard: u=user c=dashboard p= s=input.2013q4
This is not right, but not a big big deal. It's entirely possible it's caching-related or something like that. I'm going to push it off to next quarter.
Whiteboard: u=user c=dashboard p= s=input.2013q4 → u=user c=dashboard p= s=input.2014q1
Will: should we xfail the failures associated with this bug, so we can get coverage on production working?
xfailing it now is fine. I'm pretty sure I listed a bunch of options in the bug comments or the pull request.
I bet the problem is this:

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-facets-terms-facet.html#_accuracy_control

That sure seems likely. If we adjust the size, that should fix it.
I'm 99% sure it's the size thing. We're upgrading to Elasticsearch 0.90.10 soon. Along with that, I'll push out a new version of ElasticUtils. Once we update to that, we can specify a bigger size and that should fix this.

Moving this to 2014q2.
Whiteboard: u=user c=dashboard p= s=input.2014q1 → u=user c=dashboard p= s=input.2014q2
I nixed the test, so I'm going to push this off indefinitely.
Whiteboard: u=user c=dashboard p= s=input.2014q2 → u=user c=dashboard p= s=
Talked with Ricky about a similar issue with SUMO and decided to just go fix it for Input.

Grabbing this and fixing it now.
Assignee: nobody → willkg
Whiteboard: u=user c=dashboard p= s= → u=user c=dashboard p=1 s=input.2014q4
In a PR: https://github.com/mozilla/fjord/pull/366

I can't verify the fix until we verify the STR are still true in production, then deploy this, then re-check to see if the problem went away. I'll do that when I push this to production and report back whether it fixed it or not.
Erik pointed out we should probably use "shard_size" instead of "size". I created bug #1082152 for that since ElasticUtils doesn't support it, so the fix is harder to do.
Bah. I missed my deployment window. This will have to wait to go to prod until Monday.
Pushed this to prod just now. I'll verify it later.
I went through all the locales and the number on the front page matches the number after filtering on that locale. So I think this is good now. Marking as FIXED.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Product: Input → Input Graveyard
You need to log in before you can comment on or make changes to this bug.