Unintentional loop happening in the COMINTRO section

[eidec-ims]

While testing module 4 on the dev renderer, I ran into an unintentional loop in the COMINTRO section. I've run into this loop while running through the whole module and i've run into it when I've isolated the module from COMINTRO to the end. I do not have this problem on the prod renderer.

I start the COMINTRO section and run through the following input successfully:

COMINTRO
INTROWORKPOSTPAN
WORK2019POSTPAN: 1
DAYSWORKPOSTPAN: NR
LONGESTJOBPOSTPAN: 0
WORKRESPOSTPAN: 0
NUMWORKPOSTPAN: NR
INTROCURWORK

This is where the issue starts. After I select 'next' on INTROCURWORK, it takes me to the page for WORK2019POSTPAN, with the answer I already selected for it, Yes/1.

Here are the variables at the time when the issue happens. It's interesting, because it says it's adding WORK2019 to the tree, but I never actually see the page for WORK2019. Also, INTROCURWORK is being added as an array, which seems odd to me.

Note: once stuck in this loop, it will continue in this loop. If I then select No/0, it takes me to INTROCURWORK -> WORK2019POSTPAN again.

[boyd-mj]

I don't seem to have permissions to assign this issue so tagging folks: @JoeArmani @anthonypetersen @m-j-horner @Davinkjohnson

[eidec-ims]

Found an additional module 4 issue that's only happening on dev (this situation works as expected on prod):

At CURWORK1_SRC, I enter the following values:

Then on the next page, CURWORK2_SRC, the street number is displayed in the State/Province line:

The variable for Street number is CURWORKSTNUM and the variable for State/Province is CURWORKST.

There's an error that displays on the page:

'findResponseValue: (MULTIPLE FOUND - searching with startsWith)', I think the renderer is searching for a variable that starts with 'CURWORKST' and is returning 'CURWORKSTNUM' because it starts with 'CURWORKST'.

Also, once we get to CURWORKCONFIRM, the street number is displayed multiple times. I'm assuming it's possibly related to the same 'starts with' situation and is placing it at the state/province variable.

Deepti and I double checked the survey code, and all the variables looked correct. Deepti also reached out to Aminat and Rose to verify that the variable IDs matched up in data dictionary as expected and Aminat confirmed they are. Considering all of this and it's only happening on dev, I think it's potentially a renderer issue.

Here is the current module 4 markup file we are working with:
https://github.com/cyrjeant/privatequest/blob/master/module4.txt

[JoeArmani]

Found an additional module 4 issue that's only happening on dev (this situation works as expected on prod):

@eidec-ims It looks like this MULTIPLE FOUND issue will be specific to testing with these string-based variables. Great analysis btw, that was exactly the case.

It will be handled in the update (not yet in dev) to support your testing cases.

We'll test specifically for these string variables your team uses in testing and handle them with exact matching. You'll still see a console message, but this is just for my logging purposes -- I don't think this would arise in production based on our data structures, but I need to have visibility if it does.

Resolved in my current local branch:

[eidec-ims]

Hey Joe, thanks for the update. Do you have an estimate of when the update will be applied to dev?

[JoeArmani]

Yes, we're looking at midday Monday as likely for this update.

[eidec-ims]

That's great to hear, thank you!

[JoeArmani]

While testing module 4 on the dev renderer, I ran into an unintentional loop in the COMINTRO section. I've run into this loop while running through the whole module and i've run into it when I've isolated the module from COMINTRO to the end. I do not have this problem on the prod renderer.

@eidec-ims I think we have a renderer-specific caching issue where, on the renderer's first pass through, questions are rendered correctly. After editing the markup, it re-renders the survey, and some questions that should render are skipped. I'm still looking into this issue. One way to avoid the issue for now is to refresh the browser after editing markup until I have it resolved. If this is still a control flow issue, please let me know, but we seem to be routing to the correct question based on your scenario above in my most recent testing. Where possible, please use the PWA for testing.

Several other renderer-specific updates are now in dev that improve conditional rendering when 'Settings' -> 'Activate Logic' is selected. This should resolve conflicts between the renderer's behavior and the PWA behavior, which had deviated over the course of the accessibility implementation based on rendering timing and under-the-hood handling for screen readers.

Please continue to tag me where needed as we get M4 through testing and into production. Thanks.

[eidec-ims]

Hey @JoeArmani, I tested the two situations I mentioned in this issue. The address issue looks to be resolved. However, I'm still having issues with the looping at WORK2019.

Activate Logic is selected and I tried refreshing the page and clearing the JSON memory before each run. I've tried three times now, refreshing and clearing before each run.

[JoeArmani]

Hi @eidec-ims, will you either post or email me the block of markdown you're using for this?

[eidec-ims]

Experiencing a new issue only on dev. When I try to use a _SKIP for a section. Here's a snippet of the code example:

[INTROPREPANDIFF_SKIP,displayif=and(equals(SAMEJOBPREPAN,1),doesNotEqual(WORKRESPOSTPAN,0))]
Thank you for your responses. Please click "Next" to move to the next section.
< -> INTROPREWORK>

[INTROPREPANDIFF,displayif=valueEquals("SAMEJOBPREPAN",1) and valueEquals("WORKRESPOSTPAN",0)] The COVID-19 Pandemic changed many people’s workplace and commuting patterns. For example, some people commute to different workplaces or take different modes of transportation to work. Others go into the office different days of the week (such as hybrid) or telework (work remotely) full-time.

So if we get to this section and the variable values are met to display INTROPREPANDIFF_SKIP (SAMEJOBPREPAN =1 and WORKRESPOSTPAN != 0), then the text is displayed and works as usual.

However, if the variable values are met to to display INTROPREPANDIFF (SAMEJOBPREPAN =1 and WORKRESPOSTPAN = 0), then the whole page freezes and timeouts out, eventually met with a RESULT_CODE_HUNG error message once the page crashes and I need to refresh.

Note, the code above all works as expected in the prod renderer, this is a dev only issue.

[JoeArmani]

While testing module 4 on the dev renderer, I ran into an unintentional loop in the COMINTRO section. I've run into this loop while running through the whole module and i've run into it when I've isolated the module from COMINTRO to the end. I do not have this problem on the prod renderer.

Hi @eidec-ims

•This ended up being a .startsWith() issue too. It reproduced immediately with your markdown based on "WORK2019POSTPAN" and "WORK2019". The Mod 4 markdown I was working with had different naming conventions (it didn't have "WORK2019"), so it didn't reproduce in the stage version of this markdown. I have this resolved locally to support these similar text-based variables.

•The renderer caching issue will be resolved once this update is in dev.