Cancelation of order jobs is not working stable

[jzbmw]

Description

While testing TRI-1636 an issue with cancelation of order jobs was detected.

• child of Resiliency Measurements sig-release#218

Current behaviour

Requests for cancelation of order-jobs are mostly responsed with 500.

Expected behavior

Request for cancelation of existing order-jobs by correct order-job-id can be done successfully with desired result.

Steps to reproduce the Bug

DEV

[jzbmw]

• User retrieves a 200 when a job got canceled

Hints:

• https://irs.int.demo.catena-x.net/api/swagger-ui/index.html?configUrl=/api/api-docs/swagger-config#/Item%20Relationship%20Service/cancelJobByJobId
  Swagger UI

[mkanal]

The functionality is currently used by any business app. So the severity is set to low.

• We add this to known bugs section in Changelog.md @ds-alexander-bulgakov

[ds-alexander-bulgakov]

@ds-ext-kmassalski i was not able to reproduce the 500 anymore but still the cancelation seems to not work completely as expected. I believe not the whole order is canceled but only the first batch so the rest starts running after.
See for example this case:

• Order-job with 33 parts and 3 batches has been started at 10:25:34 GMT and canceled with 200 at at 10:25:41 GMT, orderId d9a6cd1c-1e8d-4b92-8d34-6f406f2a0dc3.
• The first batch has been canceled as expeted, see https://irs.dev.demo.catena-x.net/irs/orders/d9a6cd1c-1e8d-4b92-8d34-6f406f2a0dc3/batches/ece25b43-968d-40eb-8f4d-5a885c520656.
• The second batch however seems to not been affected since some jobs started to run just after the cancelation, see https://irs.dev.demo.catena-x.net/irs/orders/d9a6cd1c-1e8d-4b92-8d34-6f406f2a0dc3/batches/c25d1600-d972-4102-91c1-d54cbc56502b:
  { "orderId": "d9a6cd1c-1e8d-4b92-8d34-6f406f2a0dc3", "batchId": "c25d1600-d972-4102-91c1-d54cbc56502b", "batchNumber": 2, "batchTotal": 3, "totalJobs": 23, "startedOn": "2023-12-08T10:25:42.231020725Z", "completedOn": "2023-12-08T10:28:23.45123182Z", "jobs": [
{ "id": "a2b81845-f0c9-4b6c-b203-66f1d5f71cd1", "state": "COMPLETED", "startedOn": "2023-12-08T10:25:41.978882226Z", "completedOn": "2023-12-08T10:25:59.268127481Z" },
{ "id": "5a7c0c2b-990f-4949-a331-ac174208170f", "state": "COMPLETED", "startedOn": "2023-12-08T10:25:42.005030386Z", "completedOn": "2023-12-08T10:26:21.722231353Z" },
{ "id": "0729dd00-5687-4cac-9253-f45b185bb010", "state": "COMPLETED", "startedOn": "2023-12-08T10:25:42.027850875Z", "completedOn": "2023-12-08T10:26:21.82127798Z" },
{ "id": "11db1f52-d868-4bb1-80d6-506bdc8ff00c", "state": "COMPLETED", "startedOn": "2023-12-08T10:25:42.051992992Z", "completedOn": "2023-12-08T10:28:23.435121393Z" }, ...
• The third batch did not even start, see https://irs.dev.demo.catena-x.net/irs/orders/d9a6cd1c-1e8d-4b92-8d34-6f406f2a0dc3/batches/c4d4c31e-f4b9-43e3-8909-404940dae922:
  { "orderId": "d9a6cd1c-1e8d-4b92-8d34-6f406f2a0dc3", "batchId": "c4d4c31e-f4b9-43e3-8909-404940dae922", "batchNumber": 3, "batchTotal": 3, "totalJobs": 23, "startedOn": null, "completedOn": null, "jobs": [], "jobsInBatchChecksum": 3, "batchProcessingState": "INITIALIZED" }

Could you please have a look?

[ds-alexander-bulgakov]

The fix was partly successful. Cancelation during the first batch is running is done as expected. The CANCEL request affect the whole order now. Jobs in already started batched change the status to CANCELED, the batch itself get status PARTIAL. The next batches don´t even start and remain in status INITIALIZED.

Cancelation after the first batch is done however is not executed as expected. Currently the rest of batches is still executed after the cancelation request. IMO we should have a look again on this @ds-ext-kmassalski.
See example:
After the first two batches COMPLETED the order has been requested for CANCELATION at 11:12:05 GMT:

The third batch however is still running without any interference: