-
Feature Request
-
Resolution: Fixed
-
L3 - Default
-
None
-
None
-
None
User Story (Required on creation):
In the Java External Task Client, I can access the exception code introduced with CAM-14083.
Functional Requirements (Required before implementation):
- All External Task operations (complete, lock, unlock, set variables, handle failures, handle bpmn error, extend lock) triggered in the client can lead to exceptions that should contain the exception code provided by the process engine.
- The error code is accessible when "fetch and lock" fails
Technical Requirements (Required before implementation):
- The API methods defined in org.camunda.bpm.client.task.ExternalTaskService trigger Engine REST API endpoints; when an operation fails, each of these methods can throw an exception. These exceptions should expose the exception code [1] that the engine produced.
- When a "fetch and lock" request fails and an ErrorAwareBackoffStrategy is configured, the error code can be retrieved from the exception.
- The feature is tested using integration tests under client/src/it.
- Docs
- Javadocs exist.
- Breaking changes and deprecation notices are documented in the migration guide.
Limitations of Scope (Optional):
-
Hints (optional):
The exception types in the client might benefit from being overhauled to make their semantics clear. E.g., NotResumedException and NotAcquiredException are thrown based on the HTTP status code that is also reused for other error situations.
[1] https://stage.docs.camunda.org/manual/develop/reference/rest/overview/#exception-codes
This is the controller panel for Smart Panels app
[CAM-14762] In Java External Task Client, I can access engine error codes
| Fix Version/s | New: 7.18.0 [ 17394 ] |
| Description |
Original:
h3. User Story (Required on creation):
h3. Functional Requirements (Required before implementation): h3. Technical Requirements (Required before implementation): h3. Limitations of Scope (Optional): h3. Hints (optional): |
New:
Filling out ticket template is work-in-progress...
h3. User Story (Required on creation): h3. Functional Requirements (Required before implementation): h3. Technical Requirements (Required before implementation): h3. Limitations of Scope (Optional): h3. Hints (optional): |
| Link | New: This issue is related to SUPPORT-11322 [ SUPPORT-11322 ] |
| Description |
Original:
Filling out ticket template is work-in-progress...
h3. User Story (Required on creation): h3. Functional Requirements (Required before implementation): h3. Technical Requirements (Required before implementation): h3. Limitations of Scope (Optional): h3. Hints (optional): |
New:
h3. User Story (Required on creation):
In the Java External Task Client, I can access the exception code introduced with h3. Functional Requirements (Required before implementation): All operations triggered in the client can lead to exceptions that should contain the exception code provided by the process engine. h3. Technical Requirements (Required before implementation): The API methods defined in {{org.camunda.bpm.client.task.ExternalTaskService}} trigger Engine REST API endpoints; when an operation fails, each of these methods can throw an exception. These exceptions should expose the exception code [1] that the engine produced. h3. Limitations of Scope (Optional): Currently, no exceptions are thrown in the client when a fetch and lock request fails. This behavior shouldn't change. However, the exception code could potentially be logged. h3. Hints (optional): - [1] https://stage.docs.camunda.org/manual/develop/reference/rest/overview/#exception-codes |
| Description |
Original:
h3. User Story (Required on creation):
In the Java External Task Client, I can access the exception code introduced with h3. Functional Requirements (Required before implementation): All operations triggered in the client can lead to exceptions that should contain the exception code provided by the process engine. h3. Technical Requirements (Required before implementation): The API methods defined in {{org.camunda.bpm.client.task.ExternalTaskService}} trigger Engine REST API endpoints; when an operation fails, each of these methods can throw an exception. These exceptions should expose the exception code [1] that the engine produced. h3. Limitations of Scope (Optional): Currently, no exceptions are thrown in the client when a fetch and lock request fails. This behavior shouldn't change. However, the exception code could potentially be logged. h3. Hints (optional): - [1] https://stage.docs.camunda.org/manual/develop/reference/rest/overview/#exception-codes |
New:
h3. User Story (Required on creation):
In the Java External Task Client, I can access the exception code introduced with h3. Functional Requirements (Required before implementation): All External Task operations (complete, lock, unlock, set variables, handle failures, handle bpmn error, extend lock) triggered in the client can lead to exceptions that should contain the exception code provided by the process engine. h3. Technical Requirements (Required before implementation): * The API methods defined in {{org.camunda.bpm.client.task.ExternalTaskService}} trigger Engine REST API endpoints; when an operation fails, each of these methods can throw an exception. These exceptions should expose the exception code [1] that the engine produced. h3. Limitations of Scope (Optional): Currently, no exceptions are thrown in the client when a fetch and lock request fails. This behavior shouldn't change. However, the exception code could potentially be logged. h3. Hints (optional): The exception types in the client might be overhauled to make their semantics clear. E.g., {{NotResumedException}} and {{NotAcquiredException}} are thrown based on the HTTP status code that is also reused for other error situations. [1] https://stage.docs.camunda.org/manual/develop/reference/rest/overview/#exception-codes |
| Description |
Original:
h3. User Story (Required on creation):
In the Java External Task Client, I can access the exception code introduced with h3. Functional Requirements (Required before implementation): All External Task operations (complete, lock, unlock, set variables, handle failures, handle bpmn error, extend lock) triggered in the client can lead to exceptions that should contain the exception code provided by the process engine. h3. Technical Requirements (Required before implementation): * The API methods defined in {{org.camunda.bpm.client.task.ExternalTaskService}} trigger Engine REST API endpoints; when an operation fails, each of these methods can throw an exception. These exceptions should expose the exception code [1] that the engine produced. h3. Limitations of Scope (Optional): Currently, no exceptions are thrown in the client when a fetch and lock request fails. This behavior shouldn't change. However, the exception code could potentially be logged. h3. Hints (optional): The exception types in the client might be overhauled to make their semantics clear. E.g., {{NotResumedException}} and {{NotAcquiredException}} are thrown based on the HTTP status code that is also reused for other error situations. [1] https://stage.docs.camunda.org/manual/develop/reference/rest/overview/#exception-codes |
New:
h3. User Story (Required on creation):
In the Java External Task Client, I can access the exception code introduced with h3. Functional Requirements (Required before implementation): All External Task operations (complete, lock, unlock, set variables, handle failures, handle bpmn error, extend lock) triggered in the client can lead to exceptions that should contain the exception code provided by the process engine. h3. Technical Requirements (Required before implementation): * The API methods defined in {{org.camunda.bpm.client.task.ExternalTaskService}} trigger Engine REST API endpoints; when an operation fails, each of these methods can throw an exception. These exceptions should expose the exception code [1] that the engine produced. h3. Limitations of Scope (Optional): Currently, no exceptions are thrown in the client when a fetch and lock request fails. This behavior shouldn't change. However, the exception code could potentially be logged. h3. Hints (optional): The exception types in the client might benefit from being overhauled to make their semantics clear. E.g., {{NotResumedException}} and {{NotAcquiredException}} are thrown based on the HTTP status code that is also reused for other error situations. [1] https://stage.docs.camunda.org/manual/develop/reference/rest/overview/#exception-codes |
| Description |
Original:
h3. User Story (Required on creation):
In the Java External Task Client, I can access the exception code introduced with h3. Functional Requirements (Required before implementation): All External Task operations (complete, lock, unlock, set variables, handle failures, handle bpmn error, extend lock) triggered in the client can lead to exceptions that should contain the exception code provided by the process engine. h3. Technical Requirements (Required before implementation): * The API methods defined in {{org.camunda.bpm.client.task.ExternalTaskService}} trigger Engine REST API endpoints; when an operation fails, each of these methods can throw an exception. These exceptions should expose the exception code [1] that the engine produced. h3. Limitations of Scope (Optional): Currently, no exceptions are thrown in the client when a fetch and lock request fails. This behavior shouldn't change. However, the exception code could potentially be logged. h3. Hints (optional): The exception types in the client might benefit from being overhauled to make their semantics clear. E.g., {{NotResumedException}} and {{NotAcquiredException}} are thrown based on the HTTP status code that is also reused for other error situations. [1] https://stage.docs.camunda.org/manual/develop/reference/rest/overview/#exception-codes |
New:
h3. User Story (Required on creation):
In the Java External Task Client, I can access the exception code introduced with h3. Functional Requirements (Required before implementation): All External Task operations (complete, lock, unlock, set variables, handle failures, handle bpmn error, extend lock) triggered in the client can lead to exceptions that should contain the exception code provided by the process engine. h3. Technical Requirements (Required before implementation): * The API methods defined in {{org.camunda.bpm.client.task.ExternalTaskService}} trigger Engine REST API endpoints; when an operation fails, each of these methods can throw an exception. These exceptions should expose the exception code [1] that the engine produced. ** Add a {{#getCode}} accessor to the client exceptions to access the exception code. * Javadocs exist. * The feature is tested using integration tests under {{client/src/it}}. h3. Limitations of Scope (Optional): Currently, no exceptions are thrown in the client when a fetch and lock request fails. This behavior shouldn't change. However, the exception code could potentially be logged. h3. Hints (optional): The exception types in the client might benefit from being overhauled to make their semantics clear. E.g., {{NotResumedException}} and {{NotAcquiredException}} are thrown based on the HTTP status code that is also reused for other error situations. [1] https://stage.docs.camunda.org/manual/develop/reference/rest/overview/#exception-codes |
| Description |
Original:
h3. User Story (Required on creation):
In the Java External Task Client, I can access the exception code introduced with h3. Functional Requirements (Required before implementation): All External Task operations (complete, lock, unlock, set variables, handle failures, handle bpmn error, extend lock) triggered in the client can lead to exceptions that should contain the exception code provided by the process engine. h3. Technical Requirements (Required before implementation): * The API methods defined in {{org.camunda.bpm.client.task.ExternalTaskService}} trigger Engine REST API endpoints; when an operation fails, each of these methods can throw an exception. These exceptions should expose the exception code [1] that the engine produced. ** Add a {{#getCode}} accessor to the client exceptions to access the exception code. * Javadocs exist. * The feature is tested using integration tests under {{client/src/it}}. h3. Limitations of Scope (Optional): Currently, no exceptions are thrown in the client when a fetch and lock request fails. This behavior shouldn't change. However, the exception code could potentially be logged. h3. Hints (optional): The exception types in the client might benefit from being overhauled to make their semantics clear. E.g., {{NotResumedException}} and {{NotAcquiredException}} are thrown based on the HTTP status code that is also reused for other error situations. [1] https://stage.docs.camunda.org/manual/develop/reference/rest/overview/#exception-codes |
New:
h3. User Story (Required on creation):
In the Java External Task Client, I can access the exception code introduced with h3. Functional Requirements (Required before implementation): All External Task operations (complete, lock, unlock, set variables, handle failures, handle bpmn error, extend lock) triggered in the client can lead to exceptions that should contain the exception code provided by the process engine. h3. Technical Requirements (Required before implementation): * The API methods defined in {{org.camunda.bpm.client.task.ExternalTaskService}} trigger Engine REST API endpoints; when an operation fails, each of these methods can throw an exception. These exceptions should expose the exception code [1] that the engine produced. ** Add a field {{code}} and a {{#getCode}} accessor to {{ExternalTaskClientException}} that exposes the exception code returned by the failing REST API requests. * Javadocs exist. * The feature is tested using integration tests under {{client/src/it}}. h3. Limitations of Scope (Optional): Currently, no exceptions are thrown in the client when a fetch and lock request fails. This behavior shouldn't change. However, the exception code could potentially be logged. h3. Hints (optional): The exception types in the client might benefit from being overhauled to make their semantics clear. E.g., {{NotResumedException}} and {{NotAcquiredException}} are thrown based on the HTTP status code that is also reused for other error situations. [1] https://stage.docs.camunda.org/manual/develop/reference/rest/overview/#exception-codes |