Failed to configure networking

[CG-Spectre]

I use pretty much the same code as the activity example and DownloadNativeLibrary class. This may be an issue with Windows 11, I am not sure.

[ERROR] Failed to configure networking: ResponseError { code: TransactionAborted, message: "Transaction was aborted" }
Exception in thread "main" de.jcm.discordgamesdk.GameSDKException: Game SDK operation failed: TRANSACTION_ABORTED
    at de.jcm.discordgamesdk.Core.lambda$static$0(Core.java:386)
    at de.jcm.discordgamesdk.Core.destroy(Native Method)
    at de.jcm.discordgamesdk.Core.close(Core.java:628)
    at Discord.main(Discord.java:44)

Process finished with exit code 1

[JnCrMx]

You might want to have a look at #45. It might be the same issue. If it's not, please give more context, for example by providing the entirety of the code you are using.

[gravit0]

My users are reporting the same issue.

Failed to configure networking: ResponseError { code: TransactionAborted, message: "Transaction was aborted" }
de.jcm.discordgamesdk.GameSDKException: Game SDK operation failed: TRANSACTION_ABORTED
        at de.jcm.discordgamesdk.Core.lambda$static$0(Core.java:386)
        at de.jcm.discordgamesdk.Core.destroy(Native Method)
        at de.jcm.discordgamesdk.Core.close(Core.java:628)
        at MY CODE...

I managed to cause the problem in two ways:

1. Run the program 3 times in short time. The first 2 times everything is fine, but the third time this error appears
2. Suspend the Discord process by sending a SIGSTOP signal and restore it after a couple of seconds

Until close() is called, it is impossible to understand that something went wrong

[JnCrMx]

Is your code in any way using networking?

The first way to cause the problem might be related to some kind of rate-limits on Discord's side, generally doing a lot of operations in a short time can cause errors. And the second one doesn't really seem like an issue to me? Usually, processes should not get suspended out of nowhere, and users sending a SIGSTOP to Discord manually should be aware that it might cause unexpected behavior.

Do the operations before work, or do they get ignore/output errors as well? If they do work, I could simply recommend catching any possible exception when closing the core.

[gravit0]

Is your code in any way using networking?

No

I have not been able to find a more reliable way to reproduce this error other than the ones listed above. Sometimes the error appears randomly during normal operation for users

Do the operations before work, or do they get ignore/output errors as well? If they do work, I could simply recommend catching any possible exception when closing the core.

Very strange. All operations succeed. I don't get errors until the Core object is closed

[CG-Spectre]

I realized I opened this a while ago, i figured it out a while ago too, i forgot the loop to run callbacks. I will close this issue when @gravit0 fixes his problem, so I will keep this open until he does.

[gravit0]

i forgot the loop to run callbacks

Thanks for the answer. The callback loop is up and running but I still get this error. Are you getting an error immediately after an API call?

he

She

[JnCrMx]

@gravit0

Do the operations before work, or do they get ignore/output errors as well? If they do work, I could simply recommend catching any possible exception when closing the core.

Very strange. All operations succeed. I don't get errors until the Core object is closed

Then I assume that it is simply because a current operation is still in progress (so it was started, but the callback has not been called yet) when close is called. I think it would be safe to simply catch any TRANSACTION_ABORTED in close, as long as there are no other issues caused by this behavior.

[gravit0]

Thank you! The core object will be closed correctly after raise a exception?

[JnCrMx]

I am not sure how a Java exception is propagated through C code, so if it would be worth investigating if it is important that the Core object is closed correctly. If the Core is only closed when your program is going to end anyway, it should not be that important.

However, I am currently working at a reimplementation in pure Java, so the problem should be solved by that soon.