Well, that would seem to be my fault; I think our newly deployed changes to the code that does all the tag filter / combination / exclusion code is having a hard time with newly added tags. If I use my dev console to see what it is doing:
Parsing query...
query parsed, 0ms
Warning (invalid tags): grahas
Parsing query...
query parsed, 0ms
Warning (invalid tags): jyotish
(and with no tags that it considers "valid", it jumps into a "no results" short-cut)
The really odd thing is: it definitely knew about the tag against the question:
{
"Id": 13725,
"LastActivityDate": "2016-06-17T14:08:24Z",
"CreationDate": "2016-06-17T14:08:24Z",
...
"Tags": "|vedanta|jyotish|grahas|"
}
I've done a "dump" of the raw memory so I can reproduce it locally (just waiting for it to copy over the network), and I've restarted the service which has made it notice it:
Parsing query...
query parsed, 0ms
Switching to All over Newest/grahas (1)
Searching >>>: (all) (Newest, 1 candidates)
Filter...
Filter complete, 0ms
1 matches using 1 work units and 1 threads, related tags calculated: True
ran to completion: True (0, 0.0 %, 0 of 1)
SortRelatedTags...
SortRelatedTags complete, 0ms
kept 3 of 3 (3 question-tags)
but: this is definitely a bug and will be fixed ASAP.
Update: should be fixed now; the problem was that in part of the logic we "pre-explode" the synonyms so that we can quickly go from any tag to the effective tag; when new tags were added, the pre-exploded value was left at a default value ("no tag") unless the synonyms were re-exploded, which would happen if the synonyms were changed in some way (or if the data was re-initialized). So the relevant code interpreted the newly added tags as though they hadn't been included.
We now do a better job of handling this when new tags are added!