Honestly, not sure why this exists and why the cap
is so low. Maybe some node guy can explain this to me.
Ah well. We don't execute anything that should DOS us
and we certainly don't let user input hit this function
so, we should be good.
it's completely broken and no longer honoured. I *still* to this day do
not know why this is a bug on our systems. Maybe I will investigate it
further at some point, but for now, instanceof is banned in the codebase
as it doesn't seem to fucking work.
normally i refrain from swearing in a codebase i know future employers
will check, but this has to be one of *the* most frustrating bugs we've
had in years.
we also don't want to take advantage of an express gimmick, which
is that it likes to prefer the most "specific" route to a path.
I'd rather be far more explicit and mount these routes first.
I'm *pretty* sure it should be inheriting this from the parent tsconfig,
but it doesn't seem like it is. instanceof doesn't work if we're
compiling for ES3, and I think we might be doing that?
Every-so-often we want to run a script that works against local seeds
rather than a remote. It's inconvenient to have a variable passed to all
of the times seeds are clones, so this env var allows this to be
overridden globally. Likely only for script usage; not even documented.
Typescript sometimes decides to "compile out" prototype chains like this
we have to *enforce* that these classes have the right inheritance,
because we do instanceof checks to determine what kind of error was
thrown. We could switch to a tagged union approach, but this seems more stable.
This was giving us brownout problems. When we tried to restart all of
our things, only some of them would connect to discord. The rest
would be 429d, and not boot.
This stopped us from firing up score workers, amusingly.
zkldi