Browse Source
This bug was kind of a long one to figure out, as per #1918 documents the issue had to do with subcommands but the actual adventure in finding this one was a long one. The first problem was that Command.cog was for some reason None, which indicated that a copy was happening somewhere along the way. After some fiddling I discovered that due to the copies of `Cog.__cog_commands__` the groups pointed to out-dated versions that got overriden by the new copies. The first attempt at fixing this was straightforward -- just remove the subcommand from the parent and replace it with the newer reference that we just received. However, this ended up not working due to a strange mystery where the subcommand being invoked was neither the original copy nor the new copy residing in `Cog.__cog_commands__`. Some more investigation later pointed out to me that a copy occurs during the `Group.copy` stage which calls `Command.copy` for all its subcommands. After spotting this out I had realised where the discrepancy comes from. As it turns out, the subcommand copy that was being invoked was actually a stale one created from `Group.copy`. The question remained, how come that one was being called? The problem stemmed from the fact that when the subcommand was copied, the parent reference pointed to the old parent. Since the old parent was the one that was getting the new reference, it went practically untouched. This is because the calling code fetches the child from the parent and the old parent is nowhere in the call chain. To fix this issue we needed to update the parent reference, and in order to do that a temporary lookup table is required pointing to the latest copies that we have made. Thus ends a 3.5 hour bug hunting adventure.pull/1929/head
1 changed files with 14 additions and 0 deletions
Loading…
Reference in new issue