HTML report display limit is not working correctly since v7

[takohei]

Describe the bug

Background

To improve the performance of HTML report generation, #1306 and #1433 introduced the limit of 50 displayed records per notice type in the HTML report.

However, this limit appears to have been removed by #1935, reintroducing performance and usability issues.

Cause

In the commit 9badbe8, the logic that enforced the display limit was removed.

Previous code: <tr th:each="notice, iStat : ${noticesByCode.value}" th:if="${iStat.count <= 50}">

Current code: <tr th:each="notice: ${noticesByCode.value}">

I manually changed the line back, and then it worked correctly in my environment.

Impact

This change has caused:

• Increased HTML file size
• Longer validation times
• High browser memory usage and risk of freezing

While the impact on small feeds (e.g., 201KB) is tolerable, larger feeds often cause timeouts or browser crashes.

Additionally, this bug blocks the update of the GTFS Validator integrated in the GTFS Data Repository of Japan, which currently hosts 482 feeds, and is also interfering with a GTFS-related study project led by Japan’s Ministry of Land, Infrastructure, Transport and Tourism (MLIT).
I am involved in both of these projects.

Steps/Code to Reproduce

Validate the GTFS feed for Kumamoto City Tram: Attach, Source

Expected Results

• mixed_case_recommended_field: 50 records displayed
• non_ascii_or_non_printable_char: 50 records displayed
• HTML file size: ~1.2MB
• Chrome memory usage: ~9MB

Actual Results

• mixed_case_recommended_field: 347 records displayed
• non_ascii_or_non_printable_char: 31,183 records displayed
• HTML contains: "Only the first 50 of xxx affected records are displayed below"
  → But this is not actually enforced.
• HTML file size: 17.5MB
• Chrome memory usage: ~929MB

Screenshots

Chrome memory usage

Files used

No response

Validator version

7.0.0

Operating system

Windows 10

Java version

java version "18" 2022-03-22

Additional notes

Since the intention behind the changes in #1935 is unclear, I would appreciate it if you could confirm it.
A test case to check the display limit would also be helpful.
As this issue is currently making it difficult to update the GTFS Data Repository and carry out related study projects in Japan, I would greatly appreciate a prompt fix.

[davidgamez]

Hi @takohei, Thank you for creating the issue. We are sorry for the inconvenience. Our team will look into it.

[emmambd]

Hi @takohei — thank you for flagging this bug. This has now been fixed on the validator website. You can see that the 50 record limit has been re-applied from a new report example here: https://gtfs-validator-results.mobilitydata.org/ee9ee98d-01ba-4fa7-92d7-769e47b6e7b7/report.html

Please let us know if you have any other questions or concerns.