Fetch from Tasklist URL: embedded String

[MaxTru]

Describe the Bug

I am trying to fetch a task from Tasklist REST API using the REST POST Connector.

The post request works using CURL just fine:

curl -X 'POST' \
  'https://bru-2.tasklist.camunda.io/8da2f67e-88ab-4b38-9e39-52bb0ea4855f/v1/tasks/search' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -H "Authorization: Bearer <omitted>" \
  -d '{
      "state": "CREATED",
      "taskVariables": [
        {
          "name": "epicURL",
          "value": "\"https://github.com/camunda/product-hub/issues/1905\"",
          "operator": "eq"
        }
      ]
    }'

=> This works

Using the REST Post Connector, the Tasklist API is returning a 200, but 0 tasks. The problem is the taskVariables filter (if I omit it, then I get tasks returned). I tried the following variations:

Variant 1: (request body)

{
  state: "CREATED",
  taskVariables: [
    {
      name: "epicURL",
      value: "\"https://github.com/camunda/product-hub/issues/1905\"",
      operator: "eq"
    }
  ]
}

Variant 2: (request body)

{
  state: "CREATED",
  taskVariables: [
    {
      name: "epicURL",
      value: "https://github.com/camunda/product-hub/issues/1905",
      operator: "eq"
    }
  ]
}

Steps to Reproduce

1. Use REST POST Connector
2. Try to fetch something from Tasklist URL using the TaskVariables filter, filtering for a string value https://docs.camunda.io/docs/next/apis-tools/tasklist-api-rest/schemas/requests/task-search-request/#
3. While this works in CURL, I get 0 tasks returned via the POST Connector

Expected Behavior

I can make my CURL POST request work in the REST Connector

Environment

8.3.2 SaaS Prod Cluster

[MaxTru]

Related to https://github.com/camunda/tasklist/issues/3754

[MaxTru]

Basically: I can get this to work with CURL, but not with REST POST Connector. I don't have a way to "debug" what the REST Connector is doing here.

[sbuettner]

@MaxTru Looks like a duplicate of https://github.com/camunda/connectors/issues/239#issuecomment-1434850976 WDYT?

[MaxTru]

I investigated again.

So I provided to the Connector (via prop panel) the following:

{
  state: "CREATED",
  taskVariables: [
    {
      name: "epicURL",
      value: "\"https://github.com/camunda/product-hub/issues/1905\"",
      operator: "eq"
    }
  ]
}

This is what the REST endpoint retrieves:

{"state":"CREATED","taskVariables":[{"name":"epicURL","value":"\\\"https://github.com/camunda/product-hub/issues/1905\\\"","operator":"eq"}]}

(Formatted)

{
  "state":"CREATED",
  "taskVariables": [
     {
       "name":"epicURL",
        "value":"\\\"https://github.com/camunda/product-hub/issues/1905\\\"",
        "operator":"eq"
      }
    ]
}

[MaxTru]

@MaxTru Looks like a duplicate of #239 (comment) WDYT?

I agree Simon.

[MaxTru]

Tested on a Zeebe 8.3.4 clusteron December 15:

• Test 1 Sent this request via REST POST Connector

  • Payload as defined in the properties panel:

    {
    state: "CREATED",
    taskVariables: [
    {
    name: "epicURL",
    value: "\"https://github.com/camunda/product-hub/issues/1905\"",
    operator: "eq"
    }
    ]
    }

  • This is what the endpoint retrieves:

    {
    "state":"CREATED",
    "taskVariables":
    [
    {"name":"epicURL",
    "value":"\\\"https://github.com/camunda/product-hub/issues/1905\\\"",
    "operator":"eq"}
    ]
    }

• Test 2 Sent this request via REST POST Connector

  • Payload as defined in the properties panel:

    {
    state: "CREATED",
    taskVariables: [
    {
    name: "epicURL",
    value: "https://github.com/camunda/product-hub/issues/1905",
    operator: "eq"
    }
    ]
    }

  • This is what the endpoint retrieves:

    {
    "state":"CREATED",
    "taskVariables":
    [
    {"name":"epicURL",
    "value":"https://github.com/camunda/product-hub/issues/1905",
    "operator":"eq"}
    ]
    }

---

My take-away:

• The behavior has improved with the Zeebe fix (see test case 2)
• However, Connectors is still not useable in conjunction with Tasklist API, since Tasklist API expects `\", which is still double-escaped (see test case 1).

@sbuettner with the Zeebe side now (apparently?) fixed (ref), what is the next step?

[sbuettner]

Hi @MaxTru, thanks for testing.

Test 1: Do you know how the value looked in Operate when the connector received it?

Maybe @saig0 can provide an answer whether the first case should be covered with the latest FEEL engine fix?

Regarding Test 2: Maybe I am missing something but based on the payload you provided I cant see how it should be related to escaping.

[MaxTru]

Test 1: Do you know how the value looked in Operate when the connector received it?

Sure - see screenshot:

Regarding Test 2: Maybe I am missing something but based on the payload you provided I cant see how it should be related to escaping.

I just wanted to test that intendation works - you are right, this has nothing to do with escaping per se.

[sbuettner]

Thanks, as it arrived like this in Operate it looks like its not covered by the escaping fix as this is the data that will be handed over to the Connectors runtime and the Connector cant to much about it. @saig0 Looks like there is still some escaping taking place and maybe its related how expression results are handed over to the FEEL engine by zeebe: https://github.com/camunda/feel-scala/issues/701 cc @nicpuppa

[saig0]

@sbuettner true. We still have an issue with double quotes: https://github.com/camunda/feel-scala/issues/778