[FIX] OS argument limit can be reached by pre/post launch metadata variables

[Nyte-Sky]

When a pre/post launch script is ran, a game's metadata passed as environment variables to the script. When this metadata is too long, it can reach the OS maximum argument limit, causing the script to fail silently. This PR adds an option to instead write the metadata to a file, and pass the path to this file as a singular variable.

This fixes #5243

---

Use the following Checklist if you have changed something on the Backend or Frontend:

• Tested the feature and it's working on a current and clean install.
• Tested the main App features and they are still working on a current and clean install. (Login, Install, Play, Uninstall, Move games, etc.)
• Created / Updated Tests (If necessary)
• Created / Updated documentation (If necessary)

[flavioislima]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[Nyte-Sky]

I have read the CLA Document and I hereby sign the CLA

[arielj]

I wonder if we could make this automatic?

I'm thinking we could calculate how long the command will be if we use inline env variables and if it's more than some number we automatically use an env file?

my concerns is that users will have no idea when to use or not that, or if they have the issue they'll have no idea this check solves that issue

if we can automate that and make it transparent for the user it would be way more user-friendly

an alternative would be to never set the SETTINGS and INFO env variables and always have those in a file, then I imagine it would never be that long and we don't need an option or automate any length calculation

[Nyte-Sky]

I wanted to keep functionality the same for existing scripts that use these variables, I think it would be very confusing if your pre-launch script suddenly stops working. However, the number of people who actually use these variables is probably quite low.
It's quite a game specific issue, maybe affected games (I only know of Rocket League right now) could have a section in their documentation that says to enable it?
Or the checkbox could have some more descriptive text. Something like "OS Max Argument Workaround (May fix issues with script not launching"

[arielj]

hmmm maybe the logic of calculating the length and setting a file or not depending on that can be implemented as a way to still support scripts that currently use them and at the same time automatically fix these issues when the metadata is too long without the user having to know this issue or that there's even a limit in arguments at the OS level (for many users that will be just a lot of random tech terms)

[Nyte-Sky]

I think the issue with that is the user doesn't see whether or not their script gets a file or the direct variables. People can change their PATH, for example, and now maybe they reach the limit where before they didn't. Scripts that expect direct variables won't work for people who's system requires passing via a file. Of course we're still talking about probably a very small number of scripts that actually require game metadata at all. The most likely case I can think of is some sort of stream overlay.
The latest commit adds error handling for the scripts spawn(), with a special case for E2BIG telling users to enable the workaround. It also changes the button text to be more descriptive.

[arielj]

Since you can reproduce the issue, can you confirm if you have verboseLogs enabled for the game?

Because I see that if the spawn call fails it should print some error message in the logs but only if the game has verboseLogs enabled https://github.com/Heroic-Games-Launcher/HeroicGamesLauncher/pull/5404/changes#diff-f435a4df94baea61fbede2b6e8016c233830b8330d6104bd7ad0dec8563422ceR2127 so maybe that's why it fails silently?

I was wondering if we can catch the error message and print something in the logs like "The script couldn't run because the arguments list is too long, configure the game to use an environment file for the before/after scripts instead and use the HEROIC_METADATA_FILE env variable" (or whatever makes it clear for the user the using the option will fix the problem)

[arielj]

or maybe we need a try/catch around the line that calls await runBeforeLaunchScript(game, gameSettings, logWriter) in launcher.ts to capture this error?