winzj
commented
3 weeks ago Was a mistake it's not a bug - it is already implemented.
The product executor configuration uuid is already stored inside COLUMN_PRODUCT_CONFIG_UUID at ProductResult entity in database and is used when fetching the current product result by ProductExecutorCallbackImpl#getProductResult() which is used by adapters...
The former results are loaded from database by
AbstractProductExecutionService#runOnExecutorWithOneConfiguration()
Situation
The implementation inside
SchedulerRestartJobServicedoes purge the existing product results when it is a hard restart. In this case the restart implementation works as expected.We wanted to use the soft restart mechanism for #390 to provide the RESUME workflow for a PAUSED job in #390 , means:
New server starts Next fetched job is a PAUSED one, so we would trigger here automatically a soft restart and all should work out of the box.
Problem
Inside
PDSAdapterV1we write the PDS_JOB_UUID into the meta data via callback (from product executor) which stores it inside the product result. So far so good, but the information for the executor configuration is not stored.When it comes to soft restart inside
ScanJobExecutionRunnable, the steps there for the product executors (prepare, analysis, code scan etc.) currently always trigger a new PDS job - even when there are running PDS jobs!Wanted
ScanJobExecutionRunnable(e.g. prepare, codescan etc.) are executed ,the executors shall inspect if the product result metadata /adapter meta data does already contain a executor configuration uuid. If this is the case, the step cannot be skipped, but there is no need for a new PDS job, but the pds job uuid from meta data shall be used to fetch PDS job state ...