Millisecond Forums

+x

 

hsmartin - 12/1/2022

Hello,

One of our participants (005 in the image below) had an issue come up today. We usually send him a link to each specific session, but today when he clicked the link we had sent (https://mili2nd.co/eo6b?subjectid=005&groupid=1&sessionid=8) it had him repeat the session he completed last time (session ID 7 instead of 8). The log below shows him opening session ID 8, but somehow completing session ID 7 again (shown under data files). Any ideas on what might have happened? Thanks so much in advance!

Best,
Heather

Just a quick note: We haven't forgotton or are ignoring the session number discrepancy you pointed out. We're still puzzling over what may have caused this, though without success thus far. I will provide an update here when I have more to report.

+x

 

Dave - 12/3/2022

+x

 

hsmartin - 12/1/2022

Hello,

One of our participants (005 in the image below) had an issue come up today. We usually send him a link to each specific session, but today when he clicked the link we had sent (https://mili2nd.co/eo6b?subjectid=005&groupid=1&sessionid=8) it had him repeat the session he completed last time (session ID 7 instead of 8). The log below shows him opening session ID 8, but somehow completing session ID 7 again (shown under data files). Any ideas on what might have happened? Thanks so much in advance!

Best,
Heather

Just a quick note: We haven't forgotton or are ignoring the session number discrepancy you pointed out. We're still puzzling over what may have caused this, though without success thus far. I will provide an update here when I have more to report.

Thanks so much for the update. Also, in case it helps, I just noticed that the Inquisit version for the missed session appears to be "6.5.2" (instead of the "6.6.1" it says for all the other sessions). I'm wondering if somehow the participant was directed to an earlier version of Inquisit?

+x

 

hsmartin - 12/5/2022

+x

 

Dave - 12/3/2022

+x

 

hsmartin - 12/1/2022

Hello,

One of our participants (005 in the image below) had an issue come up today. We usually send him a link to each specific session, but today when he clicked the link we had sent (https://mili2nd.co/eo6b?subjectid=005&groupid=1&sessionid=8) it had him repeat the session he completed last time (session ID 7 instead of 8). The log below shows him opening session ID 8, but somehow completing session ID 7 again (shown under data files). Any ideas on what might have happened? Thanks so much in advance!

Best,
Heather

Just a quick note: We haven't forgotton or are ignoring the session number discrepancy you pointed out. We're still puzzling over what may have caused this, though without success thus far. I will provide an update here when I have more to report.

Thanks so much for the update. Also, in case it helps, I just noticed that the Inquisit version for the missed session appears to be "6.5.2" (instead of the "6.6.1" it says for all the other sessions). I'm wondering if somehow the participant was directed to an earlier version of Inquisit?

Technically your experiment runs under version 6.5.2 (see its settings), but the participant was using version 6.6.1. The 6.5.2 only shows up in the log because that's the nominal version and there's nothing else for session #8 (because the session number inexplicably got bumped down back to 7).

+x

 

Dave - 12/5/2022

+x

 

hsmartin - 12/5/2022

+x

 

Dave - 12/3/2022

+x

 

hsmartin - 12/1/2022

Hello,

One of our participants (005 in the image below) had an issue come up today. We usually send him a link to each specific session, but today when he clicked the link we had sent (https://mili2nd.co/eo6b?subjectid=005&groupid=1&sessionid=8) it had him repeat the session he completed last time (session ID 7 instead of 8). The log below shows him opening session ID 8, but somehow completing session ID 7 again (shown under data files). Any ideas on what might have happened? Thanks so much in advance!

Best,
Heather

Just a quick note: We haven't forgotton or are ignoring the session number discrepancy you pointed out. We're still puzzling over what may have caused this, though without success thus far. I will provide an update here when I have more to report.

Thanks so much for the update. Also, in case it helps, I just noticed that the Inquisit version for the missed session appears to be "6.5.2" (instead of the "6.6.1" it says for all the other sessions). I'm wondering if somehow the participant was directed to an earlier version of Inquisit?

Technically your experiment runs under version 6.5.2 (see its settings), but the participant was using version 6.6.1. The 6.5.2 only shows up in the log because that's the nominal version and there's nothing else for session #8 (because the session number inexplicably got bumped down back to 7).

Hi! I hope you are well. Just wanted to check in to see if there were any updates on the issue with the session number.

In case it helps, the participant who experienced this issue was different from other participants (who didn't experience the issue) in two ways: one was that he used an Android, and the other was that he was in group ID 1 rather than group ID 2. We're wondering if the issue could be specific to Androids or group 1? Or maybe it was just a temporary glitch for one participant? We're mostly hoping to make sure this isn't an issue that will replicate with future participants.

Thank you so much - we really appreciate it! Please let me know if there is any other information I can provide.

+x

 

hsmartin - 1/10/2023

+x

 

Dave - 12/5/2022

+x

 

hsmartin - 12/5/2022

+x

 

Dave - 12/3/2022

+x

 

hsmartin - 12/1/2022

Hello,

One of our participants (005 in the image below) had an issue come up today. We usually send him a link to each specific session, but today when he clicked the link we had sent (https://mili2nd.co/eo6b?subjectid=005&groupid=1&sessionid=8) it had him repeat the session he completed last time (session ID 7 instead of 8). The log below shows him opening session ID 8, but somehow completing session ID 7 again (shown under data files). Any ideas on what might have happened? Thanks so much in advance!

Best,
Heather

Just a quick note: We haven't forgotton or are ignoring the session number discrepancy you pointed out. We're still puzzling over what may have caused this, though without success thus far. I will provide an update here when I have more to report.

Thanks so much for the update. Also, in case it helps, I just noticed that the Inquisit version for the missed session appears to be "6.5.2" (instead of the "6.6.1" it says for all the other sessions). I'm wondering if somehow the participant was directed to an earlier version of Inquisit?

Technically your experiment runs under version 6.5.2 (see its settings), but the participant was using version 6.6.1. The 6.5.2 only shows up in the log because that's the nominal version and there's nothing else for session #8 (because the session number inexplicably got bumped down back to 7).

Hi! I hope you are well. Just wanted to check in to see if there were any updates on the issue with the session number.

In case it helps, the participant who experienced this issue was different from other participants (who didn't experience the issue) in two ways: one was that he used an Android, and the other was that he was in group ID 1 rather than group ID 2. We're wondering if the issue could be specific to Androids or group 1? Or maybe it was just a temporary glitch for one participant? We're mostly hoping to make sure this isn't an issue that will replicate with future participants.

Thank you so much - we really appreciate it! Please let me know if there is any other information I can provide.

The honest answer is: We don't know what caused the problem. The launch service and the licensing service rely on the same underlying backend function. The correct session number was present at launch, and the launch service picked it up correctly from the URL parameter. Just a second later, however, it's gone and the licensing service has the wrong one. What happened in-betewen is a mystery. We've reviewed the code and could not identify any bug in it. We've not been able to replicate the problem (not on Android devices, not on other systems) across a large amount of tests. While it's clear where the wrong session number came from (session numbers in the database are determined by counting finish page hits, so if not overridden by URL parameter, the system will pull that value from the database), it's not clear what made the URL parameter disappear (for lack of a better word) inbetween launch and licensing time. Any scenarion I can come up with seems wildly implausible; e.g. the participant clicking the link with the URL parameter, thereby making the launch service pick up the correct session number, but still having a tab from a previous session open in their browser (without the session ID URL parameter), and clicking the start button in that other tab; some browser plugin or security app that strips URL parameters; an Android update failing to migrate app configuration properly, thereby partly breaking its protocol handler (which, among other things, passes the launch information from the browser to the app). Something like that is possible in theory, but none of those scenarios seem particularly convincing to me.

+x

 

Dave - 1/10/2023

+x

 

hsmartin - 1/10/2023

+x

 

Dave - 12/5/2022

+x

 

hsmartin - 12/5/2022

+x

 

Dave - 12/3/2022

+x

 

hsmartin - 12/1/2022

Hello,

One of our participants (005 in the image below) had an issue come up today. We usually send him a link to each specific session, but today when he clicked the link we had sent (https://mili2nd.co/eo6b?subjectid=005&groupid=1&sessionid=8) it had him repeat the session he completed last time (session ID 7 instead of 8). The log below shows him opening session ID 8, but somehow completing session ID 7 again (shown under data files). Any ideas on what might have happened? Thanks so much in advance!

Best,
Heather

Just a quick note: We haven't forgotton or are ignoring the session number discrepancy you pointed out. We're still puzzling over what may have caused this, though without success thus far. I will provide an update here when I have more to report.

Thanks so much for the update. Also, in case it helps, I just noticed that the Inquisit version for the missed session appears to be "6.5.2" (instead of the "6.6.1" it says for all the other sessions). I'm wondering if somehow the participant was directed to an earlier version of Inquisit?

Technically your experiment runs under version 6.5.2 (see its settings), but the participant was using version 6.6.1. The 6.5.2 only shows up in the log because that's the nominal version and there's nothing else for session #8 (because the session number inexplicably got bumped down back to 7).

Hi! I hope you are well. Just wanted to check in to see if there were any updates on the issue with the session number.

In case it helps, the participant who experienced this issue was different from other participants (who didn't experience the issue) in two ways: one was that he used an Android, and the other was that he was in group ID 1 rather than group ID 2. We're wondering if the issue could be specific to Androids or group 1? Or maybe it was just a temporary glitch for one participant? We're mostly hoping to make sure this isn't an issue that will replicate with future participants.

Thank you so much - we really appreciate it! Please let me know if there is any other information I can provide.

The honest answer is: We don't know what caused the problem. The launch service and the licensing service rely on the same underlying backend function. The correct session number was present at launch, and the launch service picked it up correctly from the URL parameter. Just a second later, however, it's gone and the licensing service has the wrong one. What happened in-betewen is a mystery. We've reviewed the code and could not identify any bug in it. We've not been able to replicate the problem (not on Android devices, not on other systems) across a large amount of tests. While it's clear where the wrong session number came from (session numbers in the database are determined by counting finish page hits, so if not overridden by URL parameter, the system will pull that value from the database), it's not clear what made the URL parameter disappear (for lack of a better word) inbetween launch and licensing time. Any scenarion I can come up with seems wildly implausible; e.g. the participant clicking the link with the URL parameter, thereby making the launch service pick up the correct session number, but still having a tab from a previous session open in their browser (without the session ID URL parameter), and clicking the start button in that other tab; some browser plugin or security app that strips URL parameters; an Android update failing to migrate app configuration properly, thereby partly breaking its protocol handler (which, among other things, passes the launch information from the browser to the app). Something like that is possible in theory, but none of those scenarios seem particularly convincing to me.

Hi Dave! Thank you so much for all your help so far. We really appreciate you continuing to look into this with us! It seems this issue has come up a few times now (most recently 1/31). I have attached screenshots of the 3 times this has happened in case it can help with figuring out the problem - all 3 times, the user had an Android and was enrolled in group ID 1. I’m actually realizing this issue might be specific to group ID 1 rather than Androids, since none of our Android or iPhone users in group ID 2 have had this issue. Also, our two (and only) participants in group ID 1 have both experienced this issue. Additionally, it doesn’t seem to be an issue with tabs from previous sessions remaining open, as our participant (screenshot 009-8) experienced this skipping/repeating issue even after checking to make sure previous tabs on her web browser were closed. We really appreciate any other thoughts on this so that our group 1 participants no longer are being redirected to sessions they’ve already completed (and missing the correct sessions)!

Thanks so much,
Heather

+x

 

hsmartin - 2/3/2023

+x

 

Dave - 1/10/2023

+x

 

hsmartin - 1/10/2023

+x

 

Dave - 12/5/2022

+x

 

hsmartin - 12/5/2022

+x

 

Dave - 12/3/2022

+x

 

hsmartin - 12/1/2022

Hello,

One of our participants (005 in the image below) had an issue come up today. We usually send him a link to each specific session, but today when he clicked the link we had sent (https://mili2nd.co/eo6b?subjectid=005&groupid=1&sessionid=8) it had him repeat the session he completed last time (session ID 7 instead of 8). The log below shows him opening session ID 8, but somehow completing session ID 7 again (shown under data files). Any ideas on what might have happened? Thanks so much in advance!

Best,
Heather

Just a quick note: We haven't forgotton or are ignoring the session number discrepancy you pointed out. We're still puzzling over what may have caused this, though without success thus far. I will provide an update here when I have more to report.

Thanks so much for the update. Also, in case it helps, I just noticed that the Inquisit version for the missed session appears to be "6.5.2" (instead of the "6.6.1" it says for all the other sessions). I'm wondering if somehow the participant was directed to an earlier version of Inquisit?

Technically your experiment runs under version 6.5.2 (see its settings), but the participant was using version 6.6.1. The 6.5.2 only shows up in the log because that's the nominal version and there's nothing else for session #8 (because the session number inexplicably got bumped down back to 7).

Hi! I hope you are well. Just wanted to check in to see if there were any updates on the issue with the session number.

In case it helps, the participant who experienced this issue was different from other participants (who didn't experience the issue) in two ways: one was that he used an Android, and the other was that he was in group ID 1 rather than group ID 2. We're wondering if the issue could be specific to Androids or group 1? Or maybe it was just a temporary glitch for one participant? We're mostly hoping to make sure this isn't an issue that will replicate with future participants.

Thank you so much - we really appreciate it! Please let me know if there is any other information I can provide.

The honest answer is: We don't know what caused the problem. The launch service and the licensing service rely on the same underlying backend function. The correct session number was present at launch, and the launch service picked it up correctly from the URL parameter. Just a second later, however, it's gone and the licensing service has the wrong one. What happened in-betewen is a mystery. We've reviewed the code and could not identify any bug in it. We've not been able to replicate the problem (not on Android devices, not on other systems) across a large amount of tests. While it's clear where the wrong session number came from (session numbers in the database are determined by counting finish page hits, so if not overridden by URL parameter, the system will pull that value from the database), it's not clear what made the URL parameter disappear (for lack of a better word) inbetween launch and licensing time. Any scenarion I can come up with seems wildly implausible; e.g. the participant clicking the link with the URL parameter, thereby making the launch service pick up the correct session number, but still having a tab from a previous session open in their browser (without the session ID URL parameter), and clicking the start button in that other tab; some browser plugin or security app that strips URL parameters; an Android update failing to migrate app configuration properly, thereby partly breaking its protocol handler (which, among other things, passes the launch information from the browser to the app). Something like that is possible in theory, but none of those scenarios seem particularly convincing to me.

Hi Dave! Thank you so much for all your help so far. We really appreciate you continuing to look into this with us! It seems this issue has come up a few times now (most recently 1/31). I have attached screenshots of the 3 times this has happened in case it can help with figuring out the problem - all 3 times, the user had an Android and was enrolled in group ID 1. I’m actually realizing this issue might be specific to group ID 1 rather than Androids, since none of our Android or iPhone users in group ID 2 have had this issue. Also, our two (and only) participants in group ID 1 have both experienced this issue. Additionally, it doesn’t seem to be an issue with tabs from previous sessions remaining open, as our participant (screenshot 009-8) experienced this skipping/repeating issue even after checking to make sure previous tabs on her web browser were closed. We really appreciate any other thoughts on this so that our group 1 participants no longer are being redirected to sessions they’ve already completed (and missing the correct sessions)!

Thanks so much,
Heather

- Subject #005, session #8 on 12/1/2022 is the original case you reported. The cause remains unclear.

- Subject #009, session #4 on 1/20/2023 is the case we discussed here: https://forums.millisecond.com/Topic35152.aspx
The fact pattern is different from subject #005, session #8 and I'm reasonably certain that this was a browser issue.

- Subject #009, session #8 on 1/31/2023, same participant & device as above, shows the identical fact pattern as subject #009, session #4, i.e. a browser issue.

I am reasonably certain that the two instances involving subject #009 come down to some kind of browser tab or caching issue, because the URL parameter values appended to the finish URL indicate that the study was actually launched with parameter values of 3 (instead of 4) and 7 (instead of 8) respectively.

+x

 

Dave - 2/3/2023

+x

 

hsmartin - 2/3/2023

+x

 

Dave - 1/10/2023

+x

 

hsmartin - 1/10/2023

+x

 

Dave - 12/5/2022

+x

 

hsmartin - 12/5/2022

+x

 

Dave - 12/3/2022

+x

 

hsmartin - 12/1/2022

Hello,

One of our participants (005 in the image below) had an issue come up today. We usually send him a link to each specific session, but today when he clicked the link we had sent (https://mili2nd.co/eo6b?subjectid=005&groupid=1&sessionid=8) it had him repeat the session he completed last time (session ID 7 instead of 8). The log below shows him opening session ID 8, but somehow completing session ID 7 again (shown under data files). Any ideas on what might have happened? Thanks so much in advance!

Best,
Heather

Just a quick note: We haven't forgotton or are ignoring the session number discrepancy you pointed out. We're still puzzling over what may have caused this, though without success thus far. I will provide an update here when I have more to report.

Thanks so much for the update. Also, in case it helps, I just noticed that the Inquisit version for the missed session appears to be "6.5.2" (instead of the "6.6.1" it says for all the other sessions). I'm wondering if somehow the participant was directed to an earlier version of Inquisit?

Technically your experiment runs under version 6.5.2 (see its settings), but the participant was using version 6.6.1. The 6.5.2 only shows up in the log because that's the nominal version and there's nothing else for session #8 (because the session number inexplicably got bumped down back to 7).

Hi! I hope you are well. Just wanted to check in to see if there were any updates on the issue with the session number.

In case it helps, the participant who experienced this issue was different from other participants (who didn't experience the issue) in two ways: one was that he used an Android, and the other was that he was in group ID 1 rather than group ID 2. We're wondering if the issue could be specific to Androids or group 1? Or maybe it was just a temporary glitch for one participant? We're mostly hoping to make sure this isn't an issue that will replicate with future participants.

Thank you so much - we really appreciate it! Please let me know if there is any other information I can provide.

The honest answer is: We don't know what caused the problem. The launch service and the licensing service rely on the same underlying backend function. The correct session number was present at launch, and the launch service picked it up correctly from the URL parameter. Just a second later, however, it's gone and the licensing service has the wrong one. What happened in-betewen is a mystery. We've reviewed the code and could not identify any bug in it. We've not been able to replicate the problem (not on Android devices, not on other systems) across a large amount of tests. While it's clear where the wrong session number came from (session numbers in the database are determined by counting finish page hits, so if not overridden by URL parameter, the system will pull that value from the database), it's not clear what made the URL parameter disappear (for lack of a better word) inbetween launch and licensing time. Any scenarion I can come up with seems wildly implausible; e.g. the participant clicking the link with the URL parameter, thereby making the launch service pick up the correct session number, but still having a tab from a previous session open in their browser (without the session ID URL parameter), and clicking the start button in that other tab; some browser plugin or security app that strips URL parameters; an Android update failing to migrate app configuration properly, thereby partly breaking its protocol handler (which, among other things, passes the launch information from the browser to the app). Something like that is possible in theory, but none of those scenarios seem particularly convincing to me.

Hi Dave! Thank you so much for all your help so far. We really appreciate you continuing to look into this with us! It seems this issue has come up a few times now (most recently 1/31). I have attached screenshots of the 3 times this has happened in case it can help with figuring out the problem - all 3 times, the user had an Android and was enrolled in group ID 1. I’m actually realizing this issue might be specific to group ID 1 rather than Androids, since none of our Android or iPhone users in group ID 2 have had this issue. Also, our two (and only) participants in group ID 1 have both experienced this issue. Additionally, it doesn’t seem to be an issue with tabs from previous sessions remaining open, as our participant (screenshot 009-8) experienced this skipping/repeating issue even after checking to make sure previous tabs on her web browser were closed. We really appreciate any other thoughts on this so that our group 1 participants no longer are being redirected to sessions they’ve already completed (and missing the correct sessions)!

Thanks so much,
Heather

- Subject #005, session #8 on 12/1/2022 is the original case you reported. The cause remains unclear.

- Subject #009, session #4 on 1/20/2023 is the case we discussed here: https://forums.millisecond.com/Topic35152.aspx
The fact pattern is different from subject #005, session #8 and I'm reasonably certain that this was a browser issue.

- Subject #009, session #8 on 1/31/2023, same participant & device as above, shows the identical fact pattern as subject #009, session #4, i.e. a browser issue.

I am reasonably certain that the two instances involving subject #009 come down to some kind of browser tab or caching issue, because the URL parameter values appended to the finish URL indicate that the study was actually launched with parameter values of 3 (instead of 4) and 7 (instead of 8) respectively.

Hi Dave,

Thank you so much for your response. I have two updates in case it helps, and one new question! The first update is that I met with the participant discussed above (subject #009) and I tried to gain some more clarity on the issue with the skipped sessions. When we met, she attempted to start session 11, which opened session 9 (session 10 had opened session 9 as well). When this happened, I asked her to check the URL of the start page, and she confirmed that it ended with "sessionid=11" which leaves me confused about how this URL could have directed her to a different session.

The second update is that I started thinking the issue might be specific to sessions 4, 8, 10, and 11. Not only did participant 009 have issues with all of these sessions, but I noticed that participant 005 (where the cause of the issue remains unclear) had issues with two of those same sessions. The first issue was that we got a warning for session 4 saying "This command 'format' is obsolete and will be ignored." You helpfully helped us understand this warning in another post (https://forums.millisecond.com/Topic34975.aspx), though now I'm wondering if this could be a clue that the 4 "problem sessions" mentioned above are experiencing an issue with code that is outdated or made for previous versions of Inquisit. After participant 005 got that warning for session 4, he was unable to complete session 8.

I have a question, and I know you briefly addressed this, but just wanted to check again! I've noticed that all of the sessions that have been skipped were listed as version 6.5.2., while all the sessions with version 6.6.1. have not had issues. Additionally, the sessions skipped (all version 6.5.2.) have redirected the participant to sessions with version 6.6.1. (e.g., subject #009 couldn't complete sessions 4, 8, 10, 11, which were all version 6.5.2., but was redirected to other sessions that she was able to complete–1, 2, 3, 5, 6, 7, 9–for which all were version 6.6.1.). I know you had pointed out that the settings for our experiment have it set to run in version 6.5.2. - would it be okay for me to try switching our experiment settings so it always runs in version 6.6.1., or would that mess up any past/future data collection (or mess up how any of the current scripts function)?

I'm sorry to keep dwelling on this issue – the main reason we're concerned is that we have yet to have had a participant successfully complete one of our two study conditions (group id 1), which has created significant challenges in our study. We truly appreciate your continued patience and support.

Thanks so much,
Heather

+x

 

hsmartin - 2/10/2023

+x

 

Dave - 2/3/2023

+x

 

hsmartin - 2/3/2023

+x

 

Dave - 1/10/2023

+x

 

hsmartin - 1/10/2023

+x

 

Dave - 12/5/2022

+x

 

hsmartin - 12/5/2022

+x

 

Dave - 12/3/2022

+x

 

hsmartin - 12/1/2022

Hello,

One of our participants (005 in the image below) had an issue come up today. We usually send him a link to each specific session, but today when he clicked the link we had sent (https://mili2nd.co/eo6b?subjectid=005&groupid=1&sessionid=8) it had him repeat the session he completed last time (session ID 7 instead of 8). The log below shows him opening session ID 8, but somehow completing session ID 7 again (shown under data files). Any ideas on what might have happened? Thanks so much in advance!

Best,
Heather

Just a quick note: We haven't forgotton or are ignoring the session number discrepancy you pointed out. We're still puzzling over what may have caused this, though without success thus far. I will provide an update here when I have more to report.

Thanks so much for the update. Also, in case it helps, I just noticed that the Inquisit version for the missed session appears to be "6.5.2" (instead of the "6.6.1" it says for all the other sessions). I'm wondering if somehow the participant was directed to an earlier version of Inquisit?

Technically your experiment runs under version 6.5.2 (see its settings), but the participant was using version 6.6.1. The 6.5.2 only shows up in the log because that's the nominal version and there's nothing else for session #8 (because the session number inexplicably got bumped down back to 7).

Hi! I hope you are well. Just wanted to check in to see if there were any updates on the issue with the session number.

In case it helps, the participant who experienced this issue was different from other participants (who didn't experience the issue) in two ways: one was that he used an Android, and the other was that he was in group ID 1 rather than group ID 2. We're wondering if the issue could be specific to Androids or group 1? Or maybe it was just a temporary glitch for one participant? We're mostly hoping to make sure this isn't an issue that will replicate with future participants.

Thank you so much - we really appreciate it! Please let me know if there is any other information I can provide.

The honest answer is: We don't know what caused the problem. The launch service and the licensing service rely on the same underlying backend function. The correct session number was present at launch, and the launch service picked it up correctly from the URL parameter. Just a second later, however, it's gone and the licensing service has the wrong one. What happened in-betewen is a mystery. We've reviewed the code and could not identify any bug in it. We've not been able to replicate the problem (not on Android devices, not on other systems) across a large amount of tests. While it's clear where the wrong session number came from (session numbers in the database are determined by counting finish page hits, so if not overridden by URL parameter, the system will pull that value from the database), it's not clear what made the URL parameter disappear (for lack of a better word) inbetween launch and licensing time. Any scenarion I can come up with seems wildly implausible; e.g. the participant clicking the link with the URL parameter, thereby making the launch service pick up the correct session number, but still having a tab from a previous session open in their browser (without the session ID URL parameter), and clicking the start button in that other tab; some browser plugin or security app that strips URL parameters; an Android update failing to migrate app configuration properly, thereby partly breaking its protocol handler (which, among other things, passes the launch information from the browser to the app). Something like that is possible in theory, but none of those scenarios seem particularly convincing to me.

Hi Dave! Thank you so much for all your help so far. We really appreciate you continuing to look into this with us! It seems this issue has come up a few times now (most recently 1/31). I have attached screenshots of the 3 times this has happened in case it can help with figuring out the problem - all 3 times, the user had an Android and was enrolled in group ID 1. I’m actually realizing this issue might be specific to group ID 1 rather than Androids, since none of our Android or iPhone users in group ID 2 have had this issue. Also, our two (and only) participants in group ID 1 have both experienced this issue. Additionally, it doesn’t seem to be an issue with tabs from previous sessions remaining open, as our participant (screenshot 009-8) experienced this skipping/repeating issue even after checking to make sure previous tabs on her web browser were closed. We really appreciate any other thoughts on this so that our group 1 participants no longer are being redirected to sessions they’ve already completed (and missing the correct sessions)!

Thanks so much,
Heather

- Subject #005, session #8 on 12/1/2022 is the original case you reported. The cause remains unclear.

- Subject #009, session #4 on 1/20/2023 is the case we discussed here: https://forums.millisecond.com/Topic35152.aspx
The fact pattern is different from subject #005, session #8 and I'm reasonably certain that this was a browser issue.

- Subject #009, session #8 on 1/31/2023, same participant & device as above, shows the identical fact pattern as subject #009, session #4, i.e. a browser issue.

I am reasonably certain that the two instances involving subject #009 come down to some kind of browser tab or caching issue, because the URL parameter values appended to the finish URL indicate that the study was actually launched with parameter values of 3 (instead of 4) and 7 (instead of 8) respectively.

Hi Dave,

Thank you so much for your response. I have two updates in case it helps, and one new question! The first update is that I met with the participant discussed above (subject #009) and I tried to gain some more clarity on the issue with the skipped sessions. When we met, she attempted to start session 11, which opened session 9 (session 10 had opened session 9 as well). When this happened, I asked her to check the URL of the start page, and she confirmed that it ended with "sessionid=11" which leaves me confused about how this URL could have directed her to a different session.

The second update is that I started thinking the issue might be specific to sessions 4, 8, 10, and 11. Not only did participant 009 have issues with all of these sessions, but I noticed that participant 005 (where the cause of the issue remains unclear) had issues with two of those same sessions. The first issue was that we got a warning for session 4 saying "This command 'format' is obsolete and will be ignored." You helpfully helped us understand this warning in another post (https://forums.millisecond.com/Topic34975.aspx), though now I'm wondering if this could be a clue that the 4 "problem sessions" mentioned above are experiencing an issue with code that is outdated or made for previous versions of Inquisit. After participant 005 got that warning for session 4, he was unable to complete session 8.

I have a question, and I know you briefly addressed this, but just wanted to check again! I've noticed that all of the sessions that have been skipped were listed as version 6.5.2., while all the sessions with version 6.6.1. have not had issues. Additionally, the sessions skipped (all version 6.5.2.) have redirected the participant to sessions with version 6.6.1. (e.g., subject #009 couldn't complete sessions 4, 8, 10, 11, which were all version 6.5.2., but was redirected to other sessions that she was able to complete–1, 2, 3, 5, 6, 7, 9–for which all were version 6.6.1.). I know you had pointed out that the settings for our experiment have it set to run in version 6.5.2. - would it be okay for me to try switching our experiment settings so it always runs in version 6.6.1., or would that mess up any past/future data collection (or mess up how any of the current scripts function)?

I'm sorry to keep dwelling on this issue – the main reason we're concerned is that we have yet to have had a participant successfully complete one of our two study conditions (group id 1), which has created significant challenges in our study. We truly appreciate your continued patience and support.

Thanks so much,
Heather

Hi Heather,

(1) I am certain that the issue is not tied to specific session numbers or conditions.

(2) I am equally certain that the warning about the format command has nothing to do with the issue. The warning could not and did not prevent the scripts from running, whatever the session information.

(3) About the 6.5.2 / 6.6.1 version confusion:

> "(e.g., subject #009 couldn't complete sessions 4, 8, 10, 11, which were all version 6.5.2., but was redirected to other sessions that she was able to complete–1, 2, 3, 5, 6, 7, 9–for which all were version 6.6.1.)"

You see 6.5.2 listed as the version in those cases only because the session was not launched, not the other way around. Had the session been launched, you would see the version of the player app that was installed on the device listed there instead, exactly as what you see in the session numbers that were actually launched.

Version 6.5.2 is listed there because that is the minimum version the study requires to be installed. You can safely change the minimum version to 6.6.1 in your web experiment's settings, but that will not change anything regarding how sessions are or aren't launched. However, participants who currently have a version of the player app < 6.6.1 installed (e.g. version 6.5.2 on a Mac or Windows device) will then have to download and install 6.6.1 (or higher), otherwise the study will not launch for them. Participants on IOS or Android devices will typically already have the latest version per automatic app store updates.

As to

> " When we met, she attempted to start session 11, which opened session 9 (session 10 had opened session 9 as well). When this happened, I asked her to check the URL of the start page, and she confirmed that it ended with "sessionid=11" which leaves me confused about how this URL could have directed her to a different session. "

I have the following suspicion: Some browsers, particularly Chrome, exhibit weird and broken caching behavior at times, for the sake of speeding up page loads. It's been a while since I've last seen this, but I have personally seen instances where Chrome caches and re-executes JavaScript function calls with outdated (previously cached) information, although new information is available. Here, this would mean that Chrome cached and re-executed the call to launch session 9, despite having been instructed otherwise (qua URL parameter values of 10 or 11). I of course cannot say that this is what happened to participant #009 with certainty, that would require having the physical device at hand to perform a quasi-forensic examination. But it is a plausible theory, in that it is behavior I have seen Chrome exhibit in the past.