Cannot remove tags, selecting to delete the same tag twice induces crash

[mattmcadoo]

Gtk-Message: 23:50:46.202: GtkDialog mapped without a transient parent. This is discouraged.
Traceback (most recent call last):
  File "/usr/lib/python3.12/site-packages/GTG/gtk/browser/delete_tag.py", line 53, in on_response
    self.on_delete_confirm()
  File "/usr/lib/python3.12/site-packages/GTG/gtk/browser/delete_tag.py", line 44, in on_delete_confirm
    self.browser.app.ds.tags.remove(tag.id)
  File "/usr/lib/python3.12/site-packages/GTG/core/base_store.py", line 114, in remove
    item = self.lookup[item_id]
           ~~~~~~~~~~~^^^^^^^^^
KeyError: '11ce34cc-108b-4ef5-b0a0-1f8a00ad61da'
2024-06-15 23:50:47,946 - INFO - errorhandler:handle_response:137 - Going to exit because either of fatal error or user choice
Aborted (core dumped)

repository: https://github.com/getting-things-gnome/gtg.git
at the commit: c501ff8

Gentoo using an ebuild I modified to pull directly from Github.

Build info:

The Meson build system
Version: 1.4.1
Source dir: /var/tmp/portage/app-office/gtg-9999/work/gtg-9999
Build dir: /var/tmp/portage/app-office/gtg-9999/work/gtg-9999-build
Build type: native build
Project name: gtg
Project version: 0.6.0
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program python3 found: YES (/var/tmp/portage/app-office/gtg-9999/temp/python3.12/bin/python3)
Configuring prefix-gtg.sh using configuration
Found pkg-config: YES (/usr/bin/x86_64-pc-linux-gnu-pkg-config) 2.2.0
Run-time dependency gtk4 found: YES 4.14.4
Run-time dependency glib-2.0 found: YES 2.78.6
Run-time dependency libsecret-1 found: YES 0.21.1
Run-time dependency gtksourceview-4 found: YES 4.8.4
Configuring gtg using configuration
Configuring local-gtg using configuration
Program git found: YES (/usr/bin/git)
Configuring info.py using configuration
Program msgfmt found: YES (/usr/bin/msgfmt)
Configuring org.gnome.GTG.appdata.xml.in using configuration
Configuring org.gnome.GTG.desktop.in using configuration
Configuring org.gnome.GTG.service using configuration
Program msginit found: YES (/usr/bin/msginit)
Program msgmerge found: YES (/usr/bin/msgmerge)
Program xgettext found: YES (/usr/bin/xgettext)
Program xgettext found: YES (/usr/bin/xgettext)
Program itstool found: YES (/usr/bin/itstool)
Program msgmerge found: YES (/usr/bin/msgmerge)
Program msgfmt found: YES (/usr/bin/msgfmt)
Build targets in project: 71
NOTICE: Future-deprecated features used:
 * 0.56.0: {'meson.source_root'}

gtg 0.6.0

  User defined options
    Native files         : /var/tmp/portage/app-office/gtg-9999/temp/meson.x86_64-pc-linux-gnu.amd64.ini
    build.pkg_config_path: /var/tmp/portage/app-office/gtg-9999/temp/python3.12/pkgconfig:/usr/share/pkgconfig
    buildtype            : plain
    libdir               : lib64
    localstatedir        : /var/lib
    pkg_config_path      : /var/tmp/portage/app-office/gtg-9999/temp/python3.12/pkgconfig:/usr/share/pkgconfig
    prefix               : /usr
    sysconfdir           : /etc
    werror               : false
    wrap_mode            : nodownload
    b_lto                : false
    b_pch                : false

[mattmcadoo]

The tag does not get deleted so it's not a problem of the window not refreshing. All tags are still present when re-opening gtg

[gycsaba96]

The tag does not get deleted so it's not a problem of the window not refreshing. All tags are still present when re-opening gtg

This is an excellent observation, but the conclusion doesn't seem to be entirely correct. If you close the program after the first delete attempt, the tag is no longer present after re-opening. (The delete finishes, but the changes are only in memory when the second delete attempt crashes the program.)

There were similar problems with the tasks rooted in the GUI update process. The TagStore should override the remove method to erase the Tag object from the appropriate Gio.ListStore. Moreover, other methods should also update the previously mentioned list. E.g., if you change the parent of a tag, it appears in two places. (The TaskStore can serve as an example.)

[mattmcadoo]

The tag does not get deleted so it's not a problem of the window not refreshing. All tags are still present when re-opening gtg

This is an excellent observation, but the conclusion doesn't seem to be entirely correct. If you close the program after the first delete attempt, the tag is no longer present after re-opening. (The delete finishes, but the changes are only in memory when the second delete attempt crashes the program.)

When I initially made the report, the tag not getting deleted at all was the observed behavior (tried it several times before making the report), but right now I can't replicate that; possibly due to a dependency/package update in the last two weeks. The crash can still be induced as noted though.

Since Gentoo switched to Python 3.12 as the default, there's still some lingering packages I see that get rebuilt because of a change in it's USE flag, some related to 3.12 and some for other reasons (I default having packages rebuild for any USE flags changes).

[gycsaba96]

Maybe I have something for the case when you delete the tag only once, but it is still there after a restart. When you deleted the tag only once:

• Did you have any tasks open?
• Did you see any task pop-up when you re-opened the app?
• Did the deleted tag reappear on the sidebar right after the restart or after opening tasks?

(The main idea is that the deleted tags are getting reintroduced somehow.)

[mattmcadoo]

No open tasks when trying to delete them. No pop-ups or other types of notifications. Deleted tags reappear in the sidebar after restart.

What prompted me to delete the tags was because there were multiple ones that based on a tag but with a single letter removed. For example, there was an initial tag of "bees" I had created but there were also tags of "bee", "be", and "b" So trying to do some cleanup was what led to finding this bug.

[gycsaba96]

I have found two bugs regarding tag removal, but neither of them explains the case when the tag was deleted only once. Since this happened on an updating system, and we can not reproduce the behavior, I propose we call Part 1 resolved and focus on the GUI update problem.