Describe the bug
Instead of spruce_wood blocks, rollbacks restore spruce_log blocks
In addition, spruce_leaves in the persistent sate are not any more upon rollbacks
It looks like the problem lies upon not storing the right block upon its change, not its rollback (see screenshot)
It probably happens with equivalent blocks of other trees

To Reproduce
Steps to reproduce the behavior:

• make trees with spruce_wood and persistent:true leaves (in our case, they're generated by EWG)
• /pr pv rb b:spruce_wood,spruce_log,spruce_leaves,oak_leaves t:30d r:10
• observe the spruce_log blocks instead of spruce_wood blocks, and spruce_leaves disappear since they're not persistent any more

Expected behavior
Return the blocks as they were before, in the same state.

Screenshots

• indication that the wrong block is in the logs (no pun intended):
• restored blocks vs original blocks:

Server (please complete the following information):

• Prism Version: 2.1.7
• Server Type: Paper
• Server Version: 1.16.3

Additional context
Feel free to ask

@Narimm, I'd be glad to know what you think about @AmauryCarrade's comment. If there's an easy way to save and restore this kind of information, it would enable Prism on a much wider range of cases, IMHO.

The problem is it requires a database reset. It changes the way we store data

So the issue here is that there is data being set on these blocks that doesnt normally get set - persistance and the modified log are both nbt changes.
Prism has never rolled back this sort of custom stuff

The problem as I see it is that there is a lot of potential data and there are currently NO good methods in the Bukkit API to access it reliably. Prism will never use NMS so at this point we agree its not consistent but will resolve this as
:wontfix:

The problem as I see it is that there is a lot of potential data and there are currently NO good methods in the Bukkit API to access it reliably. Prism will never use NMS so at this point we agree its not consistent but will resolve this as :wontfix:.

Hey @Narimm! About that, are you aware that on the current (1.16 at least) Bukkit API, you can import and export block data, including all NBT data a block can have? It's exported as a String (perfect for database storage) and can be recreated using a Bukkit method (all in the Bukkit API, no NMS).

Maybe this is worth considering, as Minecraft use block data in generation and other things more and more (e.g. in the current setup, Minecraft 1.17' stalactites will not be rollback-ables properly).