Skip to content

termui shows stale bug status #235

Closed

Description

@cheshirekow

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:

termui_stale

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.

Activity

  1. cheshirekow commented on Oct 24, 2019

    @cheshirekow
    ContributorAuthor

    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).

  2. MichaelMure commented on Oct 28, 2019

    @MichaelMure
    Contributor

    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.

  3. cheshirekow commented on Oct 28, 2019

    @cheshirekow
    ContributorAuthor

    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.

  4. cheshirekow commented on Nov 13, 2019

    @cheshirekow
    ContributorAuthor

    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.

  5. MichaelMure commented on Nov 13, 2019

    @MichaelMure
    Contributor

    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 ?

  6. cheshirekow commented on Nov 14, 2019

    @cheshirekow
    ContributorAuthor

    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.

  7. MichaelMure commented on Nov 14, 2019

    @MichaelMure
    Contributor

    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.

  8. added this to the 0.6.0 milestone on Nov 17, 2019
  9. added a commit that references this issue on Nov 18, 2019
    0b2a99a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions