Failed to remap ReplayMod with StackOverflowError

[SNWCreations]

Mod Name

ReplayMod

Mod Homepage

https://www.replaymod.com

Minecraft version

1.20.1 (LTS)

Describe the bug

Failed to launch the client with ReplayMod and connector installed, failing with StackOverflowError

Steps to reproduce

1. Install FFAPI, Connector and ReplayMod (all are latest version at the moment of writing this issue post), with Forge 47.1.3 as README describes.
2. Start the client
3. Client crashes with StackOverflowError, see logs for more.

Logs

https://mclo.gs/umwL4PB

Additional context

ReplayMod version 2.6.15 for MC 1.20.1 has no failure with Connector but latest version (this post uses 2.6.20) does.

[SNWCreations]

duplicate of #1590 but leaving this open as I think it still make sense to regard it as a bug.

[Su5eD]

As our LTS support target, 1.20.1 now only receives critical fixes related to Connector bugs. Please upgrade to the latest version for mod compatibility support.

[SNWCreations]

Just thinking if this isn't a connector bug? as its remapper raises the issue.

[SNWCreations]

This is the continuation of this issue. After over a half year and a lot of research around this, I found the criticial issue which causes the mod fails to be loaded.
And sorry @Su5eD for the ping but I'm sure this is a Connector bug, or, more exactly, is a FART (ForgeAutoRenamingTool) bug.
However I don't have any idea to solve this yet.

I guess this issue also existed in upstream, so upstream would get the fix as well if this issue could be solved.

In ReplayMod 2.6.16+, it starts to include ViaVersion-related classes, and the ViaVersion API has an interface called PacketType, it has only two subclasses: ServerboundPacketType and ClientboundPacketType.
Their code looks like this:

package com.replaymod.replaystudio.lib.viaversion.api.protocol.packet;

import xyz.wagyourtail.jvmdg.j17.PermittedSubClasses;

@PermittedSubClasses({ClientboundPacketType.class, ServerboundPacketType.class}) // The source of the issue
public interface PacketType {
 // fully class body is ignored here
}

package com.replaymod.replaystudio.lib.viaversion.api.protocol.packet;

public interface ClientboundPacketType extends PacketType {
  default Direction direction() {
    return Direction.CLIENTBOUND;
  }
}

package com.replaymod.replaystudio.lib.viaversion.api.protocol.packet;

public interface ServerboundPacketType extends PacketType {
  default Direction direction() {
    return Direction.SERVERBOUND;
  }
}

So let's get into this.
The remapper starts to do remap work on ReplayMod JAR, it reaches PacketType class, found class references in the annotation, then it loads ClientboundPacketType. However, ClientboundPacketType extends PacketType, so the remapper go back into the process of loading PacketType class, then it reaches the annotation... yeah, it dropped into an infinite loop.
That's why the remapper end up with StackOverflowError,

This is the whole issue.

Code agents like Copilot suggested the "placeholders", which means putting an instance of MClass that is not fully initialized into the resolved map when requested, then runs its init code after putting the instance into the map. However this plan leads to more critical issue -- it breaks the output, making the output bytecode not loadable.

So I'm stuck there, leaving this for you to give some suggestions. I'd be glad to do code stuff by myself, just needs some help.

The post time is too late for me (UTC+8), so I'm going to sleep. Hope to see some comments on this later.

[SNWCreations]

I think I had worked it out. Preparing PR.

[SNWCreations]

Fix PR ready at Sinytra/ForgeAutoRenamingTool#2
After merging it, both 1.20.1 and 1.21.x could have an update about this by just updating FART used in Connector.
Hope to hear some reviews about this. :)