My mod creates instances of SpecialCraftingRecipe to manipulate the item components, but doesn't introduce any new items. To make the mod not require client side installation, I have a mixin into SynchronizeRecipesS2CPacket to exclude my custom recipes from the registry sync. This works as expected - my custom recipes don't show up in the recipe book, but still can be crafted by players without the mod.

That is until Fabric API 0.98. Use knownPackInfo on mod data packs to avoid registry syncing broke this behavior - recipe serializers are synchronized anyway and don't allow clients to join. Using Fabric API 0.97 or a fully vanilla client doesn't have this issue.

@kikugie This is weird, as that commit should only affect DRMs.

@jacobsjo Any opinions? @modmuss50 Maybe we should revert that change for .6?

Im not going to rush to revert it, its still marked as a beta.

I need to look at the code to be 100% sure, but I dont think it does only affect DRM though. I could be wrong. I think we need to understand the problem in detail before figuring out what to do next.

@kikugie can you provide a log or even a minimal reproduction example to help us understand the issue better?

I have no idea how the knownPackInfo could any effect on the RecipeManager. Its only used in SynchronizeRegistriesTask, which only deals with synced dynamic registries, i.e. using the DynamicRegistriesS2CPacket.

Sorry for the confusion, it seems like any fabric api release on 1.20.5+

Error log:

https://mclo.gs/ETAzinz (Ik the namespace shouldn't be minecraft, I fixed it in the mod and it produces the same error)

Steps to reproduce:

Server:

1. Create a 1.20.6 local fabric server
2. Install Elytra Trims
3. Install Fabric Language Kotlin
4. Install Fabric API
5. Launch the server

Client (FAPI)

1. Create a 1.20.6 fabric instance
2. Install Fabric API
3. Join localhost server
4. Crash linked above

Client (no FAPI)

1. Create a 1.20.6 vanilla/empty fabric instance
2. Join localhost server
3. No error is printed in the log, recipes work

Intentional desynchronization has never been supported - especially in 1.20.5, as almost every registry-related entry is synced using integer IDs. Closing as wontfix.

If there is a good use for this, maybe FAPI could add a special case, otherwise I do not see any good solution just for this. also see #2168

What is the right way to achieve this behavior then?

@kikugie In an ideal world Fabric API would offer a way to register certain stuff at the very end of the registry. However that still leaves one question: how should we handle such entries within networking? There are many pitfalls, especially since 1) another mod could sync the recipe using raw ID, 2) that probably requires per-user raw ID rewriting on server side (which is too complicated), and 3) the expected behavior is undefined in many cases.

I recommend you consult with people familiar with the field of server-side only modding, like Patbox.