graphQL: does not work properly for *Variables* as opposed to *QuestionVariables*

I have tested this for many cases and many hours.
If I filter by an exposed Variable (not QuestionVariable) in the IdentifyingData, the results are not as expected.


nPersons is a (exposed) variable (Long Integer).
There is one interview with nPersons = 3.

         identifyingData: {  
       some : {
         entity : { variable: {eq: "nPersons"}}
         valueLong : { eq: 3}  # for Long

correctly returns this interview.

If I change it to :

valueLong : { eq: 2}
it also returns this interview (wrong)!

If I change it to :

valueLong : { eq: 4}
it does not return it (correct)


valueLong : { eq: 3} returns the same interview as
valueLong : { neq: 3}

But if I use the question variable num_members (which has the same value as nPersons)
everything works correctly!

Is there some undocumented information I must supply for variables as opposed to question variables?

Thank you,

The same holds for boolean variables by the way.

In Headquarters > Interviews: “Dynamic Rules” exhibit exactly the same problem.

Presumably “Dynamic Rules” use the same graphQL query?

Dear Klaus,

As for your question:
Presumably “Dynamic Rules” use the same graphQL query? - Yes, they do.

We tried to reproduce described issue and cannot do that. The search works fine. Could you please add more information (full text of request, more information of interviews, etc.). It would be great if you do the same on server and share the result with us.

Thank you and have a good day.

I have messaged you and sent the credentials for my pds server.
Did you succeed in verifying the behavior I described?



Greetings, Klaus,
Received your message, thank you for details. It looks like you found some issue in Survey Solutions. We raised an issue to solve it.

Thanks Vladimir,
Phantastic. Let me know when you need more information, but I think I described everything I found.
Thank you,


Looking at the history of the mentioned issue, I see that it was resoved in version 22.06.4.
I just tested it with my current version 22.06.5 and confirm that the issue is fixed (after removing and reinserting the exposed variables in question).

Dear Klaus, thank you for retesting and confirming the issue is resolved.