Board WIP limits break list loading in some scenarios

Summary

The work item board lists never load new items if the WIP limit results in 4, 5, or 6 items before cut-off.

Steps to reproduce

  1. Open an issue board on GitLab.com with a list containing more than 10 issues.
  2. Set each issue's weight to 1.
  3. Set the list's weight-based WIP limit to 4. The first 10 loaded issues are split into 4 before the cut-off and 6 after it.
  4. Scroll to the bottom of the list.
  5. Observe that no additional issues load and the list ends with "Showing 10 of X issues".

The same problem occurs when the WIP limit results in 5 or 6 items before cut-off. It also affects count-based WIP limits of 4, 5, or 6 items.

It was not possible to provide a reproduction project as the WIP limits feature requires a Premium or better subscription.

What is the current bug behavior?

When a list has 4-6 items before cut-off, it only shows the 10 initially loaded items. Scrolling to the bottom does not load new work items as expected. Instead, the list ends with "Showing 10 of X issues".

There is no button to force loading of additional items. The only way to see additional items is to exit the board view and look at another list.

What is the expected correct behavior?

Scrolling down should load additional work items until all items in the list are available, regardless of where the WIP cut-off falls.

Relevant logs and/or screenshots

The affected column has 4 issues before the weight-based WIP cut-off and 6 issues after it. The footer displays "Showing 10 of 23 issues", and scrolling to the bottom does not load the remaining 13 issues.

Screenshot

Image showing the problematic scenario

Output of checks

This bug happens on GitLab.com.

Possible fixes

The implementation of the cut line has overlooked indexes. The board-card loop after the cut line restarts the indexes from zero with v-for="(item, index) in afterCutLine".

The index is then used for isObservableItem(index), which is meant to add a reload observer after every sixth item.

With 4, 5, or 6 items before cut-off, neither section reaches index 6, so neither section contains an observer to trigger loading of additional items.

An attribute on the board-card component itself actually accounts for the distinction with :index="index + list.maxIssueCount", but:

  1. The index we see in isObservableItem(index) is still the one that v-for produced.
  2. The use of list.maxIssueCount does not account for weight-based WIP limits anyway.

Additionally, the implementation of isObservableItem has two more unexpected problems:

  1. It claims to target the sixth item in every loaded ten-item set, but the index 6 it targets is actually the seventh item.
  2. It uses a modulo operation to measure "sixth item in ten-item set". This results in trigger indexes like 6, 12, 18, ..., not 6, 16, 26, ... like it was seemingly intended.

This modulo behaviour does not contribute to the bug at hand, but it could cause some other odd behaviour in boards.

Bug history

It seems odd that this bug was unnoticed for so long. It has likely existed since the cut line was initially implemented in !142847 (merged).

However, at that time there was no weight-based limit, only an issue-based limit. When using the count-based limit, teams likely usually limit developers to more than 4-6 assigned issues at a time, so the bug condition was not triggered.

But with the weight-based limit introduced in !173452 (merged), the condition can now occur irregularly. It depends on work item weights and sorting in the board's displayed window.

Edited by 🤖 GitLab Bot 🤖