Searching with attachment name on the knowledge homepage or service portal does not show all the matching attachments on the KB results page

Searching with an existing uploaded attachment name on the knowledge homepage or knowledge portal fails to show all the expected matching attachments on the KB results page. The resulting list will display only one random matching attachment.

1. Activate the "Knowledge Management - Service Portal" plugin.
   2. Navigate to "Knowledge > Articles > Published".
   3. Open one of the existing articles and click on the Checkout button.
   4. Attach an XLS file to the article with a name like "SampleXLSFile_6800kb", this will generate a new text_index event.
   5. Attach another XLS file in the same article which has the same search string in its name, for example, "Copy_SampleXLSFile_6800kb.xls". This will again create another text_index event.
   6. Wait for the two text_index events to finish processing.
   7. Publish the article.
   8. Go to the /$knowledge.do page and search for the keyword "SampleXLSFile".

Observe the KB article which has the attachments matching name is listed in the results, but it does not display all the expected matching attachments. Randomly only one of the attachments will show.
The same behavior is observed on the "Knowledge Management Service Portal" as well.

The following screenshot shows there are 2 files with the keyword "SampleXSLFile" in its name are attached to the KB article:

The screenshot below shows that searching with the term "SampleXSLFile" on the portal, the KB article is returned, but not showing all the attachments:

The screenshot below shows that searching with the term "SampleXSLFile" on the KB homepage, the article is shown without all the attachments:

After carefully considering the severity and frequency of the issue, and the cost and risk of attempting a fix, it has been decided to not address this issue in any current or near future releases. We do not make this decision lightly, and we apologize for any inconvenience.

The workaround consists in the following:

1. Set the system property glide.ts.max_token_count to a higher number than the max wordcount in the attachment, for example to a value of several millions.
2. Re-attach the intended file to the affected KB article so to trigger a new re-indexing process of the attachments.