You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test(plugin): cover the running-execution delete conflict over HTTP #109
The DELETE endpoint's 409 for running executions without force (#94, PR #105) is covered only by service-level unit tests in DynamicJobLoaderServiceTest. No HTTP-level test asserts the status code and error envelope that GlobalExceptionHandler returns for JobUnloadConflictException on DELETE /jobs/definitions/{id}.
Proposed Solution
Add an integration test that exercises DELETE /jobs/definitions/{id} while the running-execution guard rejects the request, and asserts the 409 status, the error envelope fields, and that the definition, JAR, and registration remain.
Acceptance Criteria
An HTTP-level test asserts 409 and the error envelope for a delete blocked by running executions.
The test asserts that nothing was deleted or unregistered.
The test is deterministic and does not depend on timing of real job executions.
Affected Area
Plugin lifecycle: job definition deletion tests
Out of Scope
Changing delete behavior.
Additional Context
Follow-up to #94 / PR #105. Raised by the native review suggestion R3-no-http-running-conflict-test. Note: because JobExecutionAuditListener writes history when a job starts, reaching this path may require stubbing the history check; see the related force semantics follow-up.
Correction to the last note in this issue: JobExecutionAuditListener is not attached to any job, so a running execution does not write history at start. Reaching the running-execution 409 over HTTP should not require stubbing the history check; a definition without completed synchronous runs has no history row. See #107 (comment) and #111.
Activity
fronzec commentedon Oct 17, 2026
Correction to the last note in this issue:
JobExecutionAuditListeneris not attached to any job, so a running execution does not write history at start. Reaching the running-execution 409 over HTTP should not require stubbing the history check; a definition without completed synchronous runs has no history row. See #107 (comment) and #111.