Why is King Capture with Jump Not Allowed Here?

THE QUESTION: Why is 12... jump@e5 Qxe1# not allowed in this game?: https://www.chess.com/variants/spell-chess/game/83071151/23/3

In this game versus dmytroilin (2434) I was not able to play a double jump and capture his king. Neither of us are quite sure why.

Per our discussion on the game, a double jump to capture the king is allowed in multiple similar positions, including a position where only white's queen is putting the black king in check at the moment of the double jump, and a position where only white's rook would be putting black's king in check at the moment of the double jump.

For some reason the double check seems to be contributing to the double jump checkmate not being possible for black, but we aren't sure of the exact reason.

Does anyone have a clue?

i have seen this before. As far as I can tell, it is a bug. I have no idea why it behaves that way, though.

I think it should be regarded as a bug as well. I think if the king is capturable, then the capture should always be allowed, regardless of how many pieces are threatening one's own king, etc.

The white rook pins the black queen to the king. You may not move a pinned piece, at all, if you are already in check. (Except under atomic rules etc.)

However! I did a little reverse-engineering of the variants client and this appears to be a bug. When you enter a position or make an early part of a multi-part move, it precalculates things like who is in check by which pieces/players, which pieces are pinned by which piece/player, and where king captures would have to occur. After pins are calculated, it conditionally adds an "allowBreakPin" property to mark that the pinned piece could capture the king anyway. This capture should be allowed only if:

1. The player whose king you're capturing is the one pinning your piece,
2. The player whose king you're capturing is the one putting you in check, and
3. You are not in check from anyone else

(Variant rules can be added to 4-player games too.) Condition 2 is tested by looking at a nested dict-like object of who is checking who with what ("tU" at the moment, obfuscated name). The code gets the list of players checking you by calling Object.keys on the object representing your checking players. After making sure there is at most one checking player (condition 3), it compares the single key (representing the checking player ID) to the "pinnedBy" player ID using the === operator. Unfortunately, property names/keys in JavaScript are formally strings. pinnedBy is a number, so this comparison always fails: the text "2" is not the same as the number 2. allowBreakPin is therefore never set if you are in check.

Use TypeScript, y'all.

Thanks for investigating, @Fleex255!

In this related position where the white queen is not also checking the black king, jump@e5 Qxe1# is allowed.

To check my understanding, is it allowed here because "allowBreakPin" is true for the below position? And if so, is that because black is not in check (prior to moving their queen), meaning the condition 3 works as intended, unlike in the position from the actual game (where there is a bug due to the string/number discrepancy)?
 

And in this third position jump@e5 Qxe1# is also allowed because there is no pin so the "AllowBreakPin" bug doesn't occur. Right?

Yes, that matches my understanding in both cases. If you are not in check, the buggy expression for condition 2 is not evaluated, so allowBreakPin is set correctly, recording the position of your opponent's king. If your queen is not pinned, the entire pinned-pieces bookkeeping is out of play.

To summarize for future people who just want the in game reason, the bug is that your pinned pieces cannot jump to capture the opponent's king if your king is in check.

but only pinned pieces