I'm not sure how to provide relevant information for this issue, but if there's anything I can do to help debug let me know. The problem is that I have closed a few bugs from the command line using git bug status close <id>. After that, I started the termui, but it is displaying those bugs as "open". I'm using a filter status:open label:json. However, when I press enter to show details of that bug, it says "closed". Furthermore, when I go back to the list (press "q") that bug is no longer in the open list. I took a screencast:

In the screencast note bugs 12fc493 and 71ac52e at the bottom of the list. They are both listed as "open". Then I press "enter" to view the status. Note it says "closed". Then I press "q" and go back to the list. Note that the bug has disappeared from the list.

This is observed on master from today. I deleted that and went back to the prebuilt binary from v0.5.0 so I will update if the problem seems to go away or persists.

I will note that these labels were possibly assigned "near" a termui crash (#233) so that might be related.

Yup, issue persists with v0.5.0 (though maybe crossing the version boundary is the problem? I'm not sure how far master is from 0.5.0). In the screencast above note bug 92c0d09 (also near the bottom). This bug is closed and when I open termui with v0.5.0 it appears open, as it did with master (in the video above).

The termui list is only using the cache as a source of data. When you open a bug, the whole series of commit is loaded from git and the cache is updated (I think ... not sure if it's actually updated if you don't make any change to the bug). This suggest that your cache is somehow not reflecting the actual state of those bugs. A crash can very much do that.

To check that, you can either simply delete your cache (.git/git-bug/bug-cache), or make a change to those bugs to force the update of the cache.

Ok great! I'll hold off on deleting the cache and try to spot any more bugs that incorrectly show up as open. Then I'll delete the cache and see if they show up as closed. I will report back.

Ok I got a situation where this happened again. Indeed deleting the cache seems to have fixed the stale status. However, I don't think the stale status was due to crash this time. I'm pretty sure that this happened after two pulls, with no local edits to the bug. Here is what I think the situation was:

Machine A:

• Create bug d3c0372
• git bug push

Machine B:

• git bug pull -> new bug d3c0372
• git bug termui -> verify I can see new bug, "enter" to see the detail page

Machine A:

• Close bug d3c0372
• git bug push

Machine B:

• git bug pull
• git bug termui -> d3c0372 shows "open"
• "enter" on d3c0372 -> details page shows "closed"
• q back to the main page -> d3c0372 is not longer listed with "open" bugs

When I get a chance I will try to replicate this in a controlled setting and report back.

When you do the second git bug pull do you see the bug marked as updated ? The cache is only updated for new or updated bugs.

Is this something that you can replicate ?

do you see the bug marked as updated

Yes!

This was not a controlled experiment, but I just pulled from one machine to another and paid attention to output of the pull:

Fetching remote ...

Merging data ...
0597088: updated
0cf5c71: updated
1121826: new
4a83021: updated
67bf520: updated
8acce9c: updated
95e3d45: updated
9ecefaa: updated
b597fe2: updated
c2c6767: updated
c70e22a: updated
e9d5dc5: updated
f8808eb: updated

Note that c2c6767 says "updated" when I did a pull. Then I run git bug termui and I see:

 c2c6767   open    [git-bug] [jira] Should we query the changelog after we export??  

Note that it is listed as "open". I highlight and press "enter" on this bug and:

[c2c6767] [git-bug] [jira] Should we query the changelog after we export??                                                                                                           Labels
                                                                                                                                                                                                                                                                               
 [closed] Josh Bialkowski opened this bug on Nov 11 2019                                                                                                                                git-bug                                                                                

Note that it is shown as "closed". (I did close this bug on the remote machine). Press q and c2c6767 is no longer in the list.

I think I've found the problem: in https://github.com/MichaelMure/git-bug/blob/master/bug/bug.go#L516-L602, a new slice of OperationPack is computed, but never assigned to the Bug. The correct data is written in git, but the in-memory state is incorrect. This state is used later to generate the Excerpt for the cache.

Michael Muré (MichaelMure) closed the bug 6 years ago