How is frame count (FCnt) desyncronisation managed by ChripStack? (1.0.4+)

[ElectronicallyE]

Please note that this is very similar to my post in The Things Network forum, however as this is a separate network server configuration, I believe it is reasonable to ask the same question here.

The frame count is used to track the number of transmissions made by a device and is a security measure to prevent replay attacks.

Frame-counter out of sync management

Frame-counter values less than expected must always be dropped, as the authenticity can’t be proved. E.g. it could be a replay attack.

A mismatch in frame counts where the frame counter value is greater than expected can be caused by a power or network outage, resulting in a device continuing to transmit (and increase its frame count) without these transmissions being received.

Reviewing RP002-1.0.4 Regional Parameters, it states the following:
MAX_FCNT_GAP 16384

MAX_FCNT_GAP was deprecated and removed from LoRaWAN 1.0.4 and subsequent versions.

Given that this is no longer defined by the standard, what is now the acceptable difference in frame counts between the device and the network server?

[ElectronicallyE]

Some kind people over at The Things Network forum were kind enough to answer my question which called out ChirpStack:
How is frame count (FCnt) desyncronisation managed? (1.0.4+) - TTN Network and Services / The Things Stack v3 - The Things Network