Typically nodes do not join gateways but rather joint network servers. You have an atypical case where both functions run on the same embedded computer, but it’s actually an apparent loss of session records by the network server and not the gateway that is at issue here.
The general answer is that network servers should be implemented in a way that does not lose state! That’s one reason that in most non-demo settings its better to run the network server component in the cloud and back it up. In theory a gateway-hosted server could also use a backup (persisted redis or whatever) but there might be issues with the actual implementation.
The design of LoRaWAN does not provide much mechanism to recover from a loss of server state. Generally when using OTAA you’d also use ADR, and if ADR fails after hours/days to ever get any feedback from the server, it might at that point attempt to rejoin. But this is not a strong mechanism because it is not something that is supposed to happen often; ideally joining only happens once or at most a few times in device lifetime.
Also note that LoRaWAN does not have any sort of “nack” or negative reply in either direction. If a node sends traffic (even confirmed) with invalid session keys, or with a rewound frame counter, it will receive no response at all from the server. The server might internally log the occurrence of unintelligible traffic, but there will be no negative or error reply transmitted back to the node.