Repository navigation
discussions tree does not contain all discussions #182
Description
Prerequsities
- The "Troubleshooting" section of the README did not help
- I've installed the required dependencies
- I'm on the latest version of the plugin
Bug Description
- The discussions tree does not contain all the discussions that are shown in Gitlab in the browser.
- This is because
gitlab.nvimonly makes one request for 1 page with 250 items/discussions, but Gitlab has a limit of 100 items per page.
I've implemented a naive fix in #183, but there will be a better way of getting the correct number of pages to retrieve.
Activity
harrisoncramer commentedon Feb 26, 2024
Do you actually have an MR with over 100 separate discussions? That seems kind of absurd 😆
If you do, I'd guess that you're including conversations from CI... I'd suggest using the
blacklistfunctionality if so to remove those results from the plugin...?jakubbortlik commentedon Feb 26, 2024
Hi @harrisoncramer I should have described it more clearly right away. In that particular case, there were just 55 discussion threads but also a large number of commits - a colleague just likes to commit and push every single change. And all those commit notes are only filtered out in the if block that starts at line 92 in
cmd/list_discussions.go, but they still add up to the 100 "discussions" thatgitlab.nvimis now able to process. The blacklist does not help in this case because it is only applied to the at most 100 "items" on the first "page".These cases are probably rare, but still possible and I would be grateful if
gitlab.nvimwas able to handle them correctly.jakubbortlik commentedon Feb 28, 2024
I've encountered this bug again with a MR that has just 26 discussion threads, but there are a large number of commits, some changes in the MR title, status (marked as ready, etc.).
So for my purposes, I've fixed it in this branch, that I originally submitted in #183 - that PR was broken after merging in the emojis branch, but I've fixed it now. So maybe I could open that PR again. Or I'll just use my branch before this is fixed in another way in
develop.harrisoncramer commentedon Mar 29, 2024
I'd recommend waiting until the Go Gitlab library natively supports pagination helpers, they are working on that right now: xanzy/go-gitlab#1875
jakubbortlik commentedon Feb 20, 2025
The merge request for the go library has been moved here: https://gitlab.com/gitlab-org/api/client-go/-/merge_requests/1875.
It's questionable how long it will take to get merged. It's been open for more than a year. In the meantime,
gitlab.nvimis unusable in bigger merge requests with as few as 38 comments (but with a large number of commits). I'll probably just hack together a temporary workaround for myself as I did before (#183).Edit: I've made a dirty hotfix in this branch.
harrisoncramer commentedon Mar 1, 2025
Feel free to open up a PR that fixes this with pagination, agreed that waiting for upstream is silly given how slow-moving that project is.
jakubbortlik commentedon Mar 3, 2025
There's now a new MR that seems to address pagination in
client-go. Strangely enough, it's been open by a person who's been involved in the discussion of the pending MR, so it seems the new MR will replace it, so maybe it's work waiting just a little bit longer.In any case, I'm only just in the middle of a Go course and I don't think I'd be able to fix the pagination properly (for all the other cases like reviewers, MR selection, etc.) just yet. In the meantime, I can live with using my hotfix in MRs with too many items.
Maybe when pagination is ready in
client-goI'll know enough Go to prepare a PR forgitlab.nvim.jakubbortlik commentedon Apr 10, 2025
Experimental helper functions for pagination have been added to the client-go library. The fact that the helper functions are "experimental and may be subject to breaking changes to improve the API in the future" makes me a little wary. In any case, to be able to use this feature, #448 will have to be addressed first.
jakubbortlik commentedon Nov 12, 2025
Hi, @harrisoncramer, please let me know if you intend to maintain this plugin further. I currently have at least two different branches that I'm switching between based on the functionality that I need - either complete discussion tree (this issue), suggestions (this unmerged PR), and I'd really like to get out of this situation. I completely understand that if you don't use the plugin actively, you don't have the motivation to work on it anymore, but I'd just like to know what to expect, as some time ago you expressed your intention to continue development. Thanks!