Errors for results sets 10, 11

Jeremy

unread,

Apr 25, 2021, 7:28:35 AM4/25/21

to ibexexperiments

Dear all,

I was wondering what 'errors for results sets' mean. The data after set 10 (13 subjects) were not found in the csv file.

Best wishes,

Jeremy

Alex Drummond

unread,

Apr 25, 2021, 7:30:12 AM4/25/21

to ibexexperiments

There will be more detail in the browser console, but generally it would because the data for the 10th and 11th sets of results were corrupt for some reason. Are these results submitted via the new Ibex Farm, or results imported from the old one?

Alex

--
You received this message because you are subscribed to the Google Groups "ibexexperiments" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ibexexperimen...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ibexexperiments/2f70684c-8c8a-498b-b93c-82d82abb88a3n%40googlegroups.com.

Jeremy

unread,

Apr 25, 2021, 7:39:10 AM4/25/21

to ibexexperiments

Hi Alex, it's the new ibex farm. I tried to collect some data with a new experiment, but it still shows 'Errors for results set 0'. No data was recorded.

Many thanks,

Jeremy

Alex Drummond

unread,

Apr 25, 2021, 7:40:52 AM4/25/21

to ibexexperiments

Could you email me your username and the name of the experiments in question?

Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/ibexexperiments/587d059f-b2c3-4245-af85-a57605454de5n%40googlegroups.com.

Alex Drummond

unread,

Apr 25, 2021, 9:14:22 AM4/25/21

to ibexexperiments

This was an interesting one! Short version: the issue is now fixed. Read on for details.

The background here is that the new Ibex Farm compresses results on the client side using the 'snappy' algorithm before uploading them to S3. It seems that there was some kind of issue affecting Firefox on Android that caused results compressed using this browser to decode with trailing null bytes. As the issue is browser-specific, only a couple of Jeremy's results were corrupted.

I haven't quite got to the bottom of the underlying issue, but I've done the following:

(i) Added some logic to ignore trailing null bytes when parsing decoded results.

(ii) Switched to using TextEncoder for utf-8 encoding where available. For compatibility with legacy browsers I had previously adapted some code from Google's Clojure library (https://github.com/google/closure-library/blob/8598d87242af59aac233270742c8984e2b2bdbe0/closure/goog/crypt/crypt.js#L117-L143). However, I think it's possible that there might be some kind of edge case that got triggered here (Jeremy's experiment has a bunch of Chinese text), so it's probably best to use the browser native encoder where available.

(iii) Blacklisted Firefox on Android from using results compression. (The results will still upload, just in uncompressed form.)