Update test message check

[ironage]

The test "bad query after bad query" occasionally fails with the message Unsupported query for table "TopLevel": key "non_queryable_field" is not a queryable field. From what I can tell, this might be a race on the server but our tests shouldn't care too much about the exact wording on the client side so I'm just adding this to the client test to accommodate.

[kiburtse]

How it would help? The 'reason' in failed test log looks partially garbage, no?

4: flx: query on non-queryable field results in query error message
4:   Bad query after bad query
4: -------------------------------------------------------------------------------
4: /mnt/jenkins/workspace/realm_realm-core_PR-7229@3/test/object-store/sync/flx_sync.cpp:1801
4: ...............................................................................
4: 
4: /mnt/jenkins/workspace/realm_realm-core_PR-7229@3/test/object-store/sync/flx_sync.cpp:1776: FAILED:
4: explicitly with message:
4:   �����U
4: 
4: 
4: 
4: 
4: 
4: 
4: 
4: 
4: 
4: nsupported query for table "TopLevel": key
4:   "non_queryable_field" is not a queryable field

it's as if a few delimiters and non-printable symbols were put into random parts of the original string

[coveralls-official]

Pull Request Test Coverage Report for Build james.stone_454

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.002%) to 91.798%

---

Totals
Change from base Build 1952:	-0.002%
Covered Lines:	232909
Relevant Lines:	253719

---

💛 - Coveralls

[ironage]

@kiburtse I think the garbage in the message is coming from concurrent printing to the console. If the garbage is indeed in the error message string itself, then we have a different problem and we will get the same failure again later after this is merged. So if this change doesn't fix the test, at least we have a bit more information. I couldn't reproduce this locally.

[kiburtse]

so it fails on fourth test run with exactly the same error. That means it's definitely not error type related. Also every output line is properly prepended with "4: ", so it's testing output prefix, doesn't look like concurrent output.

The second condition in "if" should still cover our case, it's just that there is also some weird symbols in between. Can we verify that this message comes from the server in this form?

[michael-wb]

@ironage - can you try rerunning these tests to see if the failure is still occurring on Jenkins, now that we're not using the docker anymore?

[ironage]

I don't recall seeing this test fail on evergreen. Maybe this was a server error that had been fixed in recent releases and because Jenkins wasn't using the correct docker image we weren't picking up the fix. See #7248. I'll close this and assume it was fixed. We can open another issue if the problem comes up again.