@amyyeung17 I think the temporary solution is actually what we want to do -- we only want to recommend "curated" lessons here, and not community lessons.

Given the above, could you please update this issue to clarify what further updates are needed? You mention "Will need to verify" in the second bullet point but I'm a bit confused about whether there's actually a bug here or not. If there's a bug, would it be possible to provide the repro steps?

Thanks!

@seanlip To be honest, this should have been include in #21486 as well. These are more potential areas of improvements rather than issues. I tried examining the backend to see if the completed nodes are organized when added finished out of order. Something like if a user finishes 2, 1, 3 would it be automatically be sorted to 1, 2, 3? The old learner dashboard does not consider these cases and returns the next in-progress node as getCompletedNodeTitles().length + 1, regardless of what node was actually completed.

Another example, out of [1, 2, 3, 4]:

• User completes 3, 1. The next in-progress lesson should be 2 and the 4 is recommended.
• User completes 1, 3. The next in-progress lesson should be 4 and the 2 is recommended.
• User completes 4 only. The next in-progress lesson should be 1 and the 2 is recommended.

I've handled this by sorting it in the frontend. However, it is fairly complicated. First, I had to loop through the story nodes and find the actual position of each completed node, since the real ids aren't representative of where they are (ex. completed ['kh', 'cd', 'pl'] out of ['op', 'kh, 'cd', 'ad', 'pl']). I would return the next in-progress and recommendation nodes based on the positions. There are a lot of edge cases to consider. Knowing that 'pl' is the most recent of the completed nodes, I loop to see if index = 0 is available. Now that I've marked 'ol' (index = 0) as in-progress, I have to loop again to find the next available node to recommend which is 'ad'.

While I'm fairly certain the completed nodes are added out of order, I think double-checking the backend would be a good idea.

Improvements that could be made in these scenarios

• If my assumption is verified, we can improve this by removing the first loop. The new problem is that we can't tell what the most recent completed node is and would need some way to track it.
• Move all of this to the backend and clean up the frontend
• If we change the recommendation system, this will need to modified and other edge cases will need to be taken care of

Ultimately, all of the code can coincide. This is more about future plans and code maintainability.