[Tech] Use DNS text queries to resolve PCI IDs (#3528)

[flavioislima]

In short: does not rely on pcids file anymore, gets the info, cache it and use it for 30 days until the cache expires.

Those Ids are used to detect the user system hardware to show on the log screen and logs.

Original PR:
Heroic-Games-Launcher/HeroicGamesLauncher#3528

• Use DNS text queries to resolve PCI IDs

We only want to clear them if we're not upgrading Heroic though (don't
want to cause a request spike when releasing an update)

To test

Just check if the system information shows fine on the logs screen.

---

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)

[BrettCleary]

LGTM. I just wonder if we should add unit tests for src/backend/utils/systeminfo/gpu/pci_ids.ts or a e2e test with qase or playwright

[flavioislima]

LGTM. I just wonder if we should add unit tests for src/backend/utils/systeminfo/gpu/pci_ids.ts or a e2e test with qase or playwright

I was looking into adding some unit tests there and since the method goes to get info on a API we don't control, we would need to mock the response and I am not sure if it adds much tbh.
Not only the response but some other methods from electron would need to be mocked as well and eventually some more, its like a hell of dependencies.

For Playwright and Qase I would need to know the exact hardware that they use and I am not sure if it is always the same and they can change it over time. Even if same hardware the Vms can change the ID since the virtualized hardware IDs are generated randomly when the machine is created I believe.

At least for tests that goes to the Log screen and check for the hardware reported there or on the logs.

So would be US adjusting the code to pass, not really useful.

[nyghtstalker]

Confirmed that I am still seeing the System Information on the Log tab in Settings.

[BrettCleary]

LGTM. I just wonder if we should add unit tests for src/backend/utils/systeminfo/gpu/pci_ids.ts or a e2e test with qase or playwright

I was looking into adding some unit tests there and since the method goes to get info on a API we don't control, we would need to mock the response and I am not sure if it adds much tbh. Not only the response but some other methods from electron would need to be mocked as well and eventually some more, its like a hell of dependencies.

For Playwright and Qase I would need to know the exact hardware that they use and I am not sure if it is always the same and they can change it over time. Even if same hardware the Vms can change the ID since the virtualized hardware IDs are generated randomly when the machine is created I believe.

At least for tests that goes to the Log screen and check for the hardware reported there or on the logs.

So would be US adjusting the code to pass, not really useful.

we already have a mock for electron. you could add an app.getGPUInfo() function to mock that.

If it is really so interdependent on every other package in the project, then it could probably be refactored so that the code is testable.

We could include a mock response from the current state of that external endpoint as well.

Either way, this code is not that critical so I'm fine with not testing