[Bug] Foundry is unusable for players when combat is initiated

[thirionlogan]

I haven't thoroughly tested exactly when this happens (my working hypothesis is when a player claims an initiative slot) At some point, when a combat encounter is initiated, the server starts getting CPU Spikes, and foundry becomes unresponsive to all of the players (but not the GM for some reason). This issue immediately gets resolved when I end the combat encounter. I created a test world with a different game system (starfinder) and tested the initiative tracker with one of my players, but it didn't have any issues.

[Lyinggod]

I had a similar issue but I think it was tied to module. I tried to troubleshoot by turning off various modules. I also had the "Raise Hand" module that was throwing errors and not working. I had to uninstalled and re-install it. In the end, I did have several modules that are still turned off but I was not able to determine if it was the "Raise Hand" module or a different module. Regardless, combat tracker is now working for me again.

[SheriffDann]

Had a similar issue, at first thought it was tied to a Monk initiative mod. Removed mods and tried again with 3 players + DM. Still had these rolling delays/CPU Spikes on Combat once a player tried to claim a slot. Player whose turn it was, their rolls weren't coming through straight away.

Wasn't able to recreate the issue with just DM and one player (local test in another browser). Added 3 PCs and had one claim a slot from the PC browser. Might be only a problem with multiple PC clients in the combat?

[mkesselm]

This issue cropped up and definitely seems related to the combat tracker/initiative claiming. GM and four players, all on respective computers, and game hosted on the Forge. Everything worked fine until combat. Rolling at initiative seemed to be affected by some small delays and issues (rolls not going through, etc.), but as soon as slots were claimed, the game desynchronized across all clients (as in, GM/host and players seeing different thing, players getting game state updates that the host wasn't even seeing, etc.) and slowed to a crawl/locked up completely. This happened twice. Was using FVTT 10 and older mods and version of the Genesys system.

[irkedIsaac]

Came here to back this one up as well! My table has decided to just go pen-and-paper for initiative tracking after figuring out that claiming slots and tracking initiative makes the game nigh-unplayable.

[thirionlogan]

From what I can tell with a quick look, I think the problem is that claiming a slot triggers this function:

export function register() {
    game.socket.on(SOCKET_NAME, async (payload: SocketPayload<ClaimInitiativeSlotData>) => {
        if (payload.operation !== SocketOperation.ClaimInitiativeSlot || !payload.data) {
            return;
        }

        const combat = game.combats.get(payload.data.combatId) as GenesysCombat | undefined;
        if (!combat) {
            console.error(`Socket received Claim Initiative payload with invalid combat ID ${payload.data.combatId}`);
            return;
        }

        await combat.claimSlot(payload.data.round, payload.data.slot, payload.data.combatantId);
    });
}

where it registers a listener, which triggers when the "ClaimInitiativeSlot" socket operation is emitted. It then calls claimSlot here:

async claimSlot(round: number, slot: number, combatantId: string) {
        if (!game.user.isGM) {
            socketEmit(SocketOperation.ClaimInitiativeSlot, {
                combatId: this.id,
                combatantId,
                round,
                slot,
            });
            return;
        }

        const claimants = { ...(this.getFlag('genesys', FLAG_CLAIMANTS) as ClaimantData | undefined) };

        if (!claimants[round]) {
            claimants[round] = {};
        }

        claimants[round][slot] = combatantId;

        await this.setFlag('genesys', FLAG_CLAIMANTS, claimants);
    }

which then (if the user is not a GM), emits the "ClaimInitiativeSlot" socket operation. This triggers the register function again and causes an infinite loop. I don't know enough about foundry or how Mezryss wants initiative to work to fix this myself, but I hope this debugging helps @Assembling-Kings

[Assembling-Kings]

I'll take a jab at figuring out this after something else I have on my queue. Thanks for the initial deep down @thirionlogan