Villagers link to the same job block/bed even if it is already claimed, and game crashes if you break that job block/bed

Some points I can add from messing around with this.

1. It doesn't seem to be just a zombie curing issue. This is happening to villages i have made and 0 zombifcations or curing has occurred.

2. Multiple villagers appear to be able to link to the same workstation and even the same bed.

3. This doesn't seem to occur on villagers who exist in villages created after the 1.20.41 update (or maybe the 40 idk i only caught it after 41)

MOST IMPORTANT I THINK!!!

1. It appears looking at the village database in Universal Minecraft tool that the file system for villages changed recently. Older villages used the format "VILLAGE_(dewelling Id number)Dwellers" or info, players, poi. However this seems to have changed recently to "VILLAGE_Overworld(dwelling ID Number)_Dwellers etc.

My older villages have both an old style format and a new style format in the save file while newer created villages just have the new format. Older villages with both formats still contain data in both the old and new file system but the older format does not change when things in the village change and is probably the village as it appeared before the format system change

When I delete the older formatted village files in an old village leaving just the new style format, initial testing appears that the bug disappears and village behavior appears normal.

I'm having the same problem, a trading hall with 21 villagers in a village, the job block when i tried to remove them (only one) the game crash with 5 seconds, the 6 librarians> it was the same with all the job blocks perma-erased with the gamecrash; thepriest (gamecrash ); the fisher (game crash); the armorer (gamecrash) with a little change > no save the last spot of the player, it sucks a lot, but thanks with the info of nether move maybe i would work for my world

We believe the crashing aspect of this issue may be fix in the 1.20.50.xx Beta/Previews - if you have the opportunity to verify that in your own worlds it would be helpful in case there is a scenario that we are unable to reproduce.

We will continue to keep this bug open to track the cause of the issue related to multiple linking.

Heya Jay, 

Thanks for the update. I have loaded the world up in the Beta/Preview as you suggested and I can confirm that the world does not crash there.

The villagers did seem to stay linked to a single block, however I was able to break the remaining job blocks without a crash, and then put them back down again at which point the villagers relinked correctly. 

When it got to nightfall, it seemed the villagers did not need me to break the beds - they seemed to sort themselves out when they couldn't get in to an empty bed, though I may have broken them before the crash previously so not 100% sure on that, either way they didn't cause a crash there either and slept "as expected". 

This affects my most recent world even though none of the villagers have been zombified or cured.  One day, a random extra villager just appeared and started sleeping in the same bed as an existing one.  I have tried breaking all beds and replacing them, replacing all workstations and replacing them and killing all villagers (obviously not simultaneously) but they consistently breed one more than the bed cap and then the extra one always sleeps on top of an exiting villager in an existing bed.  To date, my game has not crashed because of this but it is pretty annoying.

Removed the reference to curing zombie villagers from the summary, as this is happening with freshly spawned villagers as well.

In my world I see villages using both `VILLAGE_Overworld_(dwelling ID Number)` and `VILLAGE_(dwelling ID Number)`
But now I seem to have two "ghost" villages using the old format only.

So now in my world I have locations where a bed can never be used anymore: https://www.reddit.com/r/technicalminecraft/comments/18att59/beds_stopped_working_in_specific_locations/

I have downloaded the "The New Armoury - bugged" world provided by Graham and studied it with an editor program. I can confirm GoldenHelmet's observations and I think I can explain what happened at a level deeper than what a player can observe, though not at the code level. The data I extracted with the editor follows, and my analysis is at the end of this comment.

======================================
Data from file: The New Armoury - bugged.mcworld
======================================
The village I looked at is the one that appears in the attached screenshot "path error.png".

Data from VILLAGE_bde502e6-990b-4264-be1d-bb1b4c7f07e0_INFO:
Version: 1
X0: -10
X1: 54
Y0: 166
Y1: 190
Z0: 92
Z1: 156

Data from VILLAGE_bde502e6-990b-4264-be1d-bb1b4c7f07e0_POI:
(13 villagers, sorted by VillagerID)

Data from VILLAGE_Overworld_bde502e6-990b-4264-be1d-bb1b4c7f07e0_INFO:
Version: 1
X0: -10
X1: 54
Y0: 166
Y1: 190
Z0: 100
Z1: 164

Data from VILLAGE_Overworld_bde502e6-990b-4264-be1d-bb1b4c7f07e0_POI:
(45 villagers, sorted by Villager ID; "was ##" gives position in old village data POI list)

Studying the profession blocks, I see that 10 of them were owned by more than one villager. In every case, the OwnerCount value for each villager is the same, and in most cases the sum of OwnerCount and the number of villagers is -21. For each shared bed, exactly one of the owning villagers owned the same bed before the village was updated.

Two profession blocks were not shared and had OwnerCount = 1. I speculate that they were placed (or broken and replaced) by the player while trying to understand what was going wrong.

Conclusions:
Sometime after this world was opened in 1.20.40 or 1.20.41, an upgrade path copied all existing village keys in the world save to keys named the same but with "Overworld_" inserted in the key name. In at least some cases the new data was corrupted, probably later, in such a way that the OwnerCount values in the POI keys were set to negative numbers (in the studied world, values found are -1, -20, and -21).

The game logic allows POI blocks to be claimed by a villager if OwnerCount is less than Capacity. Capacity for beds and profession blocks should always be 1, and for bells should be 20. All POI entries for both the old and new village data show correct Capacity values. However, the incorrect OwnerCount values allowed beds and profession blocks to be claimed by multiple villagers because each one incremented the OwnerCount by 1, but it remained negative and therefore less than Capacity.

I experimented with a world of my own that was last opened in 1.17.41. When I first opened it in 1.20.50 and immediately closed it, the upgrade did not occur, but when I reopened it and went within simulation distance of a village, I found all 7 villages in the world had been updated, including those I didn't get close to. Spot checking, I didn't see any incorrect OwnerCount values in the updated village data, so this is either not in the upgrade logic or it's triggered by something I don't know how to reproduce.

After more study, more information:
I loaded the world (spawned in the village I studied) and watched the villagers display their frustration (lightning bolt) and happiness (green) particles for a bit, then examined the world save data again. This time I looked at beds as well as profession blocks.

11 of the earlier villagers no longer dwell in the village for some reason. Of the rest, half had beds with OwnerCount = 1, the rest still had negative values one less than before (that is, -21 changed to -22). For their profession blocks, most had OwnerCount = 1, but they were all linked to the same block. The rest had negative values one less than before. So the problem appears to be getting worse, because as OwnerCounts continue going more and more negative, each block appears available (i.e. OwnerCount < Capacity) to more and more villagers until finally they all claim the same block.

It appears that 1.20.50 had a code change to force OwnerCount to 1 whenever a villager claims a new block. While this may prevent the crash, it doesn't cure the problem of OwnerCount being negative.

To find out whether OwnerCount corruption is still happening, I loaded a world that had last been opened in 1.20.1, went to a village, and monkeyed with the villagers and POI blocks to shake up their linking. Afterward I looked at all the POI key entries and found that every bed and profession block had OwnerCount = 1. In other words, the problem of negative OwnerCounts did not recur.

So it's probably not a problem with upgrading from an earlier release. More likely it was a bug in 1.20.40 that was fixed (coincidentally?) in 1.20.41 or 1.20.50, but left behind corruption in villages that were active (i.e. within simulation distance of a player) while 1.20.40 was current.

To players affected by this problem:

This problem seems to have damaged the data of villages that were activated (by a player being near or in them) in 1.20.40. Sometimes, activating those villages in 1.20.40 or 1.20.41 would cause the game to crash.

As far as we can tell, since 1.20.50 these crashes no longer happen and no additional villages are being damaged. However, the data of damaged villages remains corrupted in a way that can cause multiple villagers to continue claiming the same bed and/or the same profession block. In other words, while they shouldn't crash the game, the damaged villages might not function correctly.

I'm sure Mojang will do their best to fix this if they can, but when data is corrupted the lost data is often unrecoverable, and even if it's fixable it might take a while for a repair to be released. So I want you to know that if you prefer, you can now (in 1.20.50) fix the damage yourself by destroying the village and rebuilding it. That can be a lot of work in some cases, I know, but it's an option some people might find preferable to waiting.

I won't explain how to rebuild a village here: If you're familiar enough with how villages work to have recognized and reported this issue, you probably already know how to do it. But if you don't know, I'd suggest asking for help on the Minecraft Community Support Discord.