camunda-community-hub / camunda-space-traders Goto Github PK

Description

Currently, there is no automated QA for the SDK. Only a manual test. This may lead to bugs and regressions.

We should set up a test pipeline that runs for every PR and verifies that the current SDK version works with the current SpaceTraders API.

Describe the bug

The fulfill contract task doesn't work. On execution, it reports an incident with the failure message Error during json mapping.

To Reproduce
Steps to reproduce the behavior:

1. Run the process block to deliver contract goods when all goods are delivered
2. Verify that an incident is created at the fulfill contract task

Expected behavior
I can fulfill a contract.

Environment

• SDK/Connector template version? 4

Additional context

Is your feature request related to a problem? Please describe.
The SpaceTraders API uses standard HTTP response codes to indicate the success or failure of an API request: https://docs.spacetraders.io/api-guide/response-errors

In an automated process with the SDK is likely that a call returns a failure, for example, if the ship is not at the expected location. I want to be able to handle these failures in the process.

Describe the solution you'd like
I can configure the error handling in the SDK connector template. Same as for the Camunda REST connector: https://docs.camunda.io/docs/components/connectors/use-connectors/#bpmn-errors.

Describe alternatives you've considered
None.

Additional context

Description

The SDK supports error handling by extracting the error code and error message from the SpaceTraders response.

Currently, the error code and message are extracted from the connector's error message by using FEEL string functions. It works but it is not very reliable.

With Camunda 8.3.3. it should be possible to access the error code and message directly from the response body. For example:

if error.code = "400" and response.body.error.code = 4236 
then bpmnError(response.body.error.code, response.body.error.message)
else null

Important: to access the error from the response body, it must be mapped in the result expression. The result expression is evaluated first. The output is the input for the error expression.

Describe the bug
I use the SDK to extract resources. If a ship extracts resources and the mining laser has a cooldown then the operation fails.

I want to handle the failure case in the process via error event. But currently, I can't catch the error and an incident is created with the message:

409 Conflict
POST https://api.spacetraders.io/v2/my/ships/SG_18_1-3/extract
{"error":{"message":"Ship action is still on cooldown for 30 second(s).","code":4000,"data":{"cooldown":{"shipSymbol":"SG_18_1-3","totalSeconds":70,"remainingSeconds":30,"expiration":"2023-12-22T13:39:48.194Z"}}}}

To Reproduce
Steps to reproduce the behavior:

1. Use the SDK to extract resources two times without waiting in between
2. Verify that an incident is created

Expected behavior
I can catch the cooldown error with the error code cooldownConflictError in the BPMN error event.

Environment

• SDK/Connector template version? 4

Additional context

Is your feature request related to a problem? Please describe.
The SpaceTraders API is subject to rate limits: https://docs.spacetraders.io/api-guide/rate-limits
Allowed requests: 2 per second. When the limit is reached, the API returns with status 429.

In an automated process with the SDK is likely that it reaches the limit and the tasks fail.

Describe the solution you'd like
I can configure the number of retries and the time between the retries.

The SDK sets default values to cover major use cases.

Describe alternatives you've considered
None.

Additional context

camunda/connectors#1469

  "groups": [
    ...
    {
      "id": "responseMapping",
      "label": "Response Mapping"
    },
    {
      "id": "retries",
      "label": "API Retries"
    },
    ...
    [at the end]
    {
      "id": "retryCount",
      "label": "Retries",
      "description": "Number of retries",
      "value": "10",
      "feel": "optional",
      "group": "retries",
      "binding": {
        "property": "retries",
        "type": "zeebe:taskDefinition"
      },
      "type": "String"
    },
    {
      "id": "retryBackoff",
      "label": "Retry backoff",
      "description": "ISO-8601 duration to wait between retries",
      "value": "PT1S",
      "feel": "optional",
      "group": "retries",
      "binding": {
        "key": "retryBackoff",
        "type": "zeebe:taskHeader"
      },
      "type": "String"
    }