The attached datapack contains a suite of advancements that use functions and /schedule to remove themselves after a certain delay–immediately, after a 1 tick schedule, and after a 2 ticks schedule, one set having display information, and the other set not.
To reproduce, load the datapack in singleplayer and grant yourself each of the advancements in the test namespace in turn. When removing the 1-tick advancement with no display, the game output will receive a warning: "Told to remove advancement test:no_display_1t but I don't know what that is".
Given the output of the other advancements (the display and immediate no-display advancements give no messages, while the 2-tick no-display advancement says the game "Forgot about advancement test:no_display_2t") I'm guessing that this has to do with the advancement tree–an advancement that removes itself in its own function reward never tries to add itself to the tree, but 1t scheduling bypasses that and causes the game to try to remove the advancement from the tree before it's actually been added to it.
Linked issues
Attachments
Comments 6
They're almost certainly related, given that they can produce the same error message, but I don't know enough about the internals at play to have any idea whether or not the error's being produced for the same reason. In 130320 there's multiple advancements with the same reward function doing what looks like infinitely recursively granting/revoking themselves every tick and I don't know how the system handles that, whereas here there's no recursion or delay, just a 1t schedule command.
This may be a simpler-to-parse method of invoking whatever behavior is causing 130320, or it might be a different problem entirely that simply happens to trigger the same error message. I don't know enough to say.
Still occurs in 1.18.1.
Additionally, after looking into the code, this seems to be a debug message accidentally left set to WARNING by the developers. The reason for why this doesn't trigger anytime an advancement is changed: Mojang spaghetti code. Sometimes when removing linked advancements, it'll attempt to remove one twice, which causes this warning.
Does MC-130320 describe the problem?