Embers Rekindled does not have any chunk loaders, but they are common in other mods. When using chunk loaders, ember packets behave quite badly. I have not yet confirmed if this is with ALL types of chunk loaders, or just the particular kind that I am using (AE2s Spatial Anchor). Embers is one of my fave mods, so I'm down to help test more things if more info is needed!

My current theory is this happens when ember bursts try to travel from a loaded chunk through an unloaded chunk. Bursts normally decay after spending too long in the air, but this can't happen if they enter an unloaded chunk. Thus, many bursts can build up in an unloaded chunk. When a player logs on, and the chunk they've built up in becomes loaded, it invariably causes a server crash (assuming they've been allowed to build up for long enough). I believe it has to do with unloaded chunks because, in my testing, the server doesn't crash until I log back on - and load in all of the chunks around my base that aren't in range of the chunk loader.

I've included an image below to showcase how they can build up to quite significant numbers over time. This is with Embers Rekinded version 1.4.0 on MC version 1.20.1 with Forge version 47.4.0

Fixed in version 1.4.1

Ember bursts generally shouldn't be entering unloaded chunks for long periods of time since emitters won't send a burst if the receptor isn't loaded as well. Though in some edge cases it still happens and I guess chunk loaders just make it more likely to happen.
I could make bursts despawn if they've been unloaded for too long but I think it would suck for people to lose that much ember and I suspect it would still crash in the situation you're describing.

Maybe a config option for ember bursts to despawn if they've been unloaded too long? I've used Embers in a number of packs and never had this issue before, so I can't imagine it's a common issue. A config would mean people could make bursts despawn when lingering in unloaded chunks too long if they are experiencing this issue, but if they aren't then the normal behavior is fine?

I could add that but I don't think it will fix the crash. Ember bursts can only despawn when they're loaded, I can despawn them if they're too old as soon as they get loaded but they'll still get loaded and probably crash the server.

I've figured out how this bug happens, it's pretty easy to replicate.

When an emitter wants to send a packet, it checks if its destination is in a loaded chunk, however it does not check if the path to that destination is loaded. If a packet's path takes it into an unloaded chunk, it will accumulate there until the chunk they're stuck in is loaded.

The following setup will result in the accumulation of packets when the player travels far enough away such that the emitter and receiver are loaded, but the two chunks the packets go through are not:

I left it going in the appropriate setup for a couple minutes, and I already accumulated over 100 packets.

One potential solution is to just check if all chunks along the path are loaded before sending a packet, which should be easy because you already determine the path it takes when the connection is made.

Ah, yeah, that's a good point huh? Dang, there might not actually be a clean fix then. Unfortunate, but at least the issue is one that seems rare to run into. On another note, while I'm still not 100%, I do have a theory as to how the bug happens.

Unlike most chunk loaders, the AE2 Spatial Anchor can load unusual patterns of chunks, as opposed to the standard 3x3, 5x5, etc. chunk areas. I think the issue arises when the Emitter and Receiver are both loaded, but relays in a chunk between them aren't. That would lead to ember being sent through an unloaded chunk, and because the packet never arrives, the receiver never fills up, and the emitter just keeps sending more. Also explains why I've never encountered this particular issue before despite using Embers for years - most chunk loaders aren't capable of creating weird patterns like this.

In the rare cases where it does come up, the only fix I know of is to use commands to /kill all ember packets. But thankfully, it is at least a situation that should be quite difficult to accidentally run into. Maybe no actual code fix, and instead just add a line somewhere in the Codex mentioning that if you're using Chunk Loaders to always ensure that the entire path the ember travels along is loaded?

Emitters actually do check if the entire line of relays is loaded when firing a burst, but like Sirplop pointed out, it doesn't check the full trajectory of the burst.
I could check if all the chunks in the trajectory are loaded but I don't really want to do that for every burst so I'd have to cache it somehow. The problem is that if relays are used, the full trajectory can change without the emitter being aware of it.

On top of that, it's possible to use a beam splitter to convert a blast from the beam cannon into ember bursts which can then go into unloaded chunks, the beam cannon (intentionally) does not check its destination before firing. You can also intercept a burst on its way to a receiver with a relay and send it in a completely unexpected direction, you'd basically have to do that on purpose but it can happen.

After thinking about it a bit more I think I have a pretty good solution that will fix this in most of the common cases, it won't be perfect but it will most likely fix it for your case. There might only be 2 or 3 people who know embers on a technical enough level to run into edge cases beyond that, myself included.