While debugging a hanging forge datagen process in GTCEu-Modern, we have discovered a case where exceptions are not logged (or at least not logged early enough).
In the following case, the RegistrateDataProvider hangs indefinitely without logging the underlying exception:
subProvider B depends on the output of subProvider A
subProvider A throws an exception, causing subProvider B not to complete
Here you can see the debugger view, the breakpoint is set at the returnStatement of RegistrateDataProvider#run:
The last subProvider ended up finishing normally afterwards, but the RegistrateItemTagsProvider depended on the RegistrateTagsProvider.IntrinsicImpl#IntrinsicImpl above it.
The following is a screenshot of the list to be used in the return statement:
You can see that list[4] is not completed, but depends on list[3], which had completed exceptionally.
This caused the datagen process to hang indefinitely, as the calling code was waiting for the RegistrateDataProvider to complete.
In case one of the subProviders fails, please consider logging the exception immediately.
While debugging a hanging forge datagen process in GTCEu-Modern, we have discovered a case where exceptions are not logged (or at least not logged early enough).
In the following case, the
RegistrateDataProviderhangs indefinitely without logging the underlying exception:Here you can see the debugger view, the breakpoint is set at the returnStatement of
RegistrateDataProvider#run:The last subProvider ended up finishing normally afterwards, but the
RegistrateItemTagsProviderdepended on theRegistrateTagsProvider.IntrinsicImpl#IntrinsicImplabove it.The following is a screenshot of the list to be used in the return statement:
You can see that
list[4]is not completed, but depends onlist[3], which had completed exceptionally. This caused the datagen process to hang indefinitely, as the calling code was waiting for theRegistrateDataProviderto complete.In case one of the subProviders fails, please consider logging the exception immediately.