Nothing happens when clicking on `Jump to next unresolved thread`

when clicking on Jump to next unresolved thread noting happens and a js error appears in console.

got pointed that it might be related to #230900 (closed)

I wonder if this is somehow related to: !36164 (merged).

That MR is entirely additive (it doesn't modify the existing jump behavior), so I don't know how it would break this, but this and that MR are highly related.

@acroitor can you provide steps to reproduce and an example MR where this is happening to the MR description, please?

Is this happening on gitlab.com at the moment? In master?'

I just tested it on a couple of random MRs, in the Overview and the Changes tab. It worked as expected.

This is where it's happening:

   const discussion = self.getDiscussion(targetId);
>  const discussionFilePath = discussion.diff_file?.file_path;

Which is weird, given the diff_file? optional chaining is present.

Edit: I guess getDiscussion is not returning any discussion. We need to figure out why and in which scenario this happens.

self.getDiscussion will return null any time the currentDiscussionId is null, which - in theory - is lots of times, since that's how it starts.

I'm interested to see the reproduction instructions for this, because it sounds like an edge case I don't know about relating to that MR above (which sets currentDiscussionId to null to force it to resolve to the first ID when triggering jumpToNext...

That said, I'm not sure how it could ever remain null in that scenario (since it immediately jumps to a discussion)...

I think it happens when you are on Changes tab and MR has an unresolved discussion, but it is not related to the diff. Clicking the button generates the js error

E.g. !37799 (diffs)

added devopscreate frontend groupsource code merge requests regression labels

added typebug label

This issue has regression without specifying which milestone introduced it. We're assuming that it's introduced in the current version 13.3.0-pre so we're labeling regression:13.3.

Please correct it accordingly and keep regression so that we could easily search for all the regressions across version, too.

added regression:13.3 label

assigned to @iamphill

mentioned in commit c0e020b8

mentioned in merge request !38391 (merged)

mentioned in commit b0c2a781

mentioned in commit 1b70276a

mentioned in issue #233318 (closed)

changed milestone to %13.3

@pedroms looking at this report... shouldn't we address this scenario with some UX tweak? Potentially we can detect that we do have some unresolved threads but not in the current tab. Should we display a warning asking the user whether they want to switch tabs? Any other ideas? :D

@andr3 if the action is broken, there are not many options other than:

1. Disable the button and explain to the user that they have to switch tabs
2. Hide the button when there are no threads in the active tab
3. Improve the behavior so that it switches tabs to navigate across the threads

The first two are “hacks” in that they are compensating for the unexpected behavior. If possible, we should address the root cause for this by tackling option 3.

closed with merge request !38391 (merged)

mentioned in commit 4f27df25

added Category:Code Review Workflow groupcode review labels and removed groupsource code label