Assign Task API is not working

Hi All,

I am using Camunda 8 version Task List API for assigning a task to a user. I am initiating the request from the postman with JWT bearer token with request body as shown below.
RequestBody: {
“assignee”: “tata.admin”,
“allowOverrideAssignment”: true
}

I’m using Authentication bearer token generated by keycloak using client credentials ,It’s returning

{
  "status": 400,
  "message": "This operation is not supported using Tasklist V1 API. Please use the latest API. For more information, refer to the documentation: null",
  "instance": "c3711db7-9d11-476e-bef8-ec8c17485a8d"
}

I have also tried assigning user using zeebe client , it’s not working and there are no errors
client.newUserTaskAssignCommand(2251799813685385l).assignee(“tata.admin”).send();
but I can’t find new version of tasklist API anywhere , any leads or ideas how to achieve this.

Thank you in advance

@nathan.loding @Praveen_Kumar_Reddy @aravindhrs @Niall

Hi @Mukesh_Reddy

I believe that the user task’s implementation in your case is set as zeebe user task.

Operations on Zeebe user tasks which modify the task state have to be performed using the new Zeebe REST API

https://docs.camunda.io/docs/apis-tools/tasklist-api-rest/migrate-to-zeebe-user-tasks/#use-the-new-zeebe-task-api

Yes @hassang the user task’s implementation is set as zeebe user task

image

And I have tried to complete the userTask using zeebe client

The code :

final ZeebeClientBuilder builder = ZeebeClient.newClientBuilder().defaultTenantId(“tata”)
.gatewayAddress(“0.0.0.0:26500”).applyEnvironmentVariableOverrides(false).usePlaintext().credentialsProvider(
new CredentialsProvider() {
@Override
public boolean shouldRetryRequest(StatusCode statusCode) {
// TODO Auto-generated method stub
return false;
}

    					@Override
    					public void applyCredentials(CredentialsApplier applier) throws IOException {
    						// TODO Auto-generated method stub
    	
    						applier.put("Authorization", "Bearer "+accessToken);	}
    						
    					
    				});
    	    // Build the Zeebe client
    	    final ZeebeClient client = builder .build();	

@Override
public void completeTask(Map<String, Object> variables) {

	try {
		client.newUserTaskCompleteCommand(2251799813685584l).variables(variables).send().get();
	} catch (InterruptedException e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	} catch (ExecutionException e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	}
	 
}

The error it’s displaying is : Caused by: io.camunda.zeebe.client.api.command.ClientException: org.apache.hc.client5.http.HttpHostConnectException: Connect to http://0.0.0.0:8080 [/0.0.0.0] failed: Connection refused: getsockopt
at io.camunda.zeebe.client.impl.http.ApiCallback.failed(ApiCallback.java:69)
at org.apache.hc.core5.concurrent.BasicFuture.failed(BasicFuture.java:138)
at org.apache.hc.core5.concurrent.ComplexFuture.failed(ComplexFuture.java:79)
at org.apache.hc.client5.http.impl.async.InternalAbstractHttpAsyncClient$2.failed(InternalAbstractHttpAsyncClient.java:350)
at org.apache.hc.client5.http.impl.async.AsyncRedirectExec$1.failed(AsyncRedirectExec.java:248)
at org.apache.hc.client5.http.impl.async.AsyncHttpRequestRetryExec$1.failed(AsyncHttpRequestRetryExec.java:197)
at org.apache.hc.client5.http.impl.async.AsyncProtocolExec$1.failed(AsyncProtocolExec.java:295)
at org.apache.hc.client5.http.impl.async.AsyncConnectExec$2.failed(AsyncConnectExec.java:223)
at org.apache.hc.core5.concurrent.CallbackContribution.failed(CallbackContribution.java:47)
at org.apache.hc.core5.concurrent.BasicFuture.failed(BasicFuture.java:138)
at org.apache.hc.core5.concurrent.ComplexFuture.failed(ComplexFuture.java:79)
at org.apache.hc.client5.http.impl.nio.PoolingAsyncClientConnectionManager$4.failed(PoolingAsyncClientConnectionManager.java:479)
at org.apache.hc.core5.concurrent.BasicFuture.failed(BasicFuture.java:138)
at org.apache.hc.core5.concurrent.ComplexFuture.failed(ComplexFuture.java:79)
at org.apache.hc.client5.http.impl.nio.DefaultAsyncClientConnectionOperator$1.failed(DefaultAsyncClientConnectionOperator.java:140)
at org.apache.hc.core5.concurrent.BasicFuture.failed(BasicFuture.java:138)
at org.apache.hc.core5.concurrent.ComplexFuture.failed(ComplexFuture.java:79)
at org.apache.hc.client5.http.impl.nio.MultihomeIOSessionRequester$2$1.failed(MultihomeIOSessionRequester.java:164)
at org.apache.hc.core5.concurrent.BasicFuture.failed(BasicFuture.java:138)
at org.apache.hc.core5.reactor.IOSessionRequest.failed(IOSessionRequest.java:78)
at org.apache.hc.core5.reactor.InternalConnectChannel.onException(InternalConnectChannel.java:108)
at org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:55)
at org.apache.hc.core5.reactor.SingleCoreIOReactor.processEvents(SingleCoreIOReactor.java:178)
at org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:127)
at org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:86)
at org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
… 1 more
Caused by: org.apache.hc.client5.http.HttpHostConnectException: Connect to http://0.0.0.0:8080 [/0.0.0.0] failed: Connection refused: getsockopt
at java.base/sun.nio.ch.Net.pollConnect(Native Method)
at java.base/sun.nio.ch.Net.pollConnectNow(Net.java:682)
at java.base/sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:973)
at org.apache.hc.core5.reactor.InternalConnectChannel.onIOEvent(InternalConnectChannel.java:70)
at org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
… 5 more

I have also tried the zeebe-API http://localhost:8080/v1/user-tasks/:userTaskKey/completion

even with valid taskKey it’s showing task not found

image

Any Idea how to complete a zeebe user task using zeebe client or how to address this issue

Thank you in advance.

Hello Camunda team,

I am facing the same issue.

Summary of issue report

Multi-tenancy is enabled. I am using Zeebe user tasks and at least two of the Zeebe REST API endpoints are returning NOT_FOUND: the endpoints for [assigning](https://docs.camunda.io/docs/apis-tools/zeebe-api-rest/specifications/assign-a-user-task/) and [updating](https://docs.camunda.io/docs/apis-tools/zeebe-api-rest/specifications/update-a-user-task/) a user task.

The error is

java.util.concurrent.CompletionException: io.camunda.zeebe.client.api.command.ProblemException: Failed with code 404: 'Not Found'. Details: 'class ProblemDetail {
    type: about:blank
    title: NOT_FOUND
    status: 404
    detail: Command 'CLAIM' rejected with code 'NOT_FOUND': Expected to claim user task with key '<here is the key>', but no such user task was found
    instance: /v1/user-tasks/<here is the key>/assignment
}'

Details

The user task is visible in the Tasklist GUI so it does exist.

Also, my multi-tenancy setup should be correct: The calls to the Zeebe gRPC endpoints works without any issues in the same setup.

In Identity I have configured the Zeebe Application like this:

  • the tenant, to which the user task belongs, is assigned to the Zeebe application
  • all built-in APIs (all relating to Tasklist, all relating to Zeebe, etc.) are added in the “Access to APIs” tab
  • I even assigned the Default tenant to the Zeebe application, just to try it out.

Many thanks and kind regards,
bpmnenthusiast

P.S. One idea that I have what the problem might be is: As I have experienced, the defaultTenantId that is provided to the ZeebeClientBuilder is not correctly used when actual API calls are made. In my case, I had to provide the tenantId in the actual calls. However, for the /assignment call there is no way to provide a tenant in the Java library method call. Is it possible that the tenant is not set correctly for the call, so the actually existing user task is not found?

Hello @Mukesh_Reddy ,

to one of the errors that you received:

Caused by: io.camunda.zeebe.client.api.command.ClientException: org.apache.hc.client5.http.HttpHostConnectException: Connect to http://0.0.0.0:8080 [/0.0.0.0] failed: Connection refused: getsockopt

I also had this and it was a mismatch between the Zeebe REST API Port that the Docker container exposed and the port that the client side used. Maybe this helps you for this particular problem.

However, I am still facing the NOT_FOUND error.

Kind regards,
bpmnenthusiast

Hey @bpmnenthusiast you mean the configuration in docker.yml file for zeebe REST API and the configuration I have done while building zeebe client ?
docker-compose.yaml (15.5 KB)

There is no zeebe REST API Port set for zeebe service in docker yml , can you please look into this if i miss anything ?

Hello @Mukesh_Reddy ,

yes, I mean the configs you mentioned. The Zeebe REST API Endpoint is defined on line 20 of ‘docker-compose.yaml’. So it would be port 8088. However, it can change slightly depending on the available ports. So it would be best to check in your Docker Engine which port is taken when the container is running.

Hello @nathan.loding ,

sorry to mention you explicitly. Could you please have a look at the problem with the Zeebe REST endpoints when Identity authentication is enabled that I described in my first comment? Our integrating Camunda 8 is currently being blocked by this issue.

Many thanks and kind regards,
bpmnenthusiast

Hey @bpmnenthusiast I have given the correct port number while creating zeebe client

final ZeebeClientBuilder builder = ZeebeClient.newClientBuilder()
.defaultTenantId(“tata”)
.gatewayAddress(“localhost:8080”) // Replace with your actual broker address and port
.applyEnvironmentVariableOverrides(false)
.usePlaintext()
.credentialsProvider(new CredentialsProvider() {
@Override
public boolean shouldRetryRequest(StatusCode statusCode) {
return false;
}

		        @Override
		        public void applyCredentials(CredentialsApplier applier) throws IOException {
		            applier.put("Authorization", "Bearer " + accessToken);
		        }
		    });

		final ZeebeClient zb = builder.build();

		        
	
	try {
		zb.newUserTaskCompleteCommand(2251799813685589l).variables(variables).send().get();
	} catch (InterruptedException e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	} catch (ExecutionException e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	}

still it’s showing same error , it’s showing three ports running in docker for zeebe , I have tried with alternate port num in above gateway address , can you send how you configured it in yml or is there any mistake in above approach.
image

Thank you

Hello @Mukesh_Reddy ,

please try port 8088.

Hey @Mukesh_Reddy and @bpmnenthusiast - it looks like there’s at least two, maybe three, separate things going on in the thread. So let me try to address those one by one:

  1. The connection exception is a networking issue - either an issue with the Docker configuration, the port the client is using, or something in between. Based on the provided configuration, I agree with @bpmnenthusiast’s conclusion: @Mukesh_Reddy, try port 8088, not port 8080 (which you currently have in the Java client config), and see if that works.
  2. When using the Zeebe client, you need to provide two URLs: the gRPC endpoint and the REST endpoint. (See docs here.) You would use .grpcAddress(ZEEBE_GRPC_ADDRESS) and/or .restAddress(ZEEBE_REST_ADDRESS). Try explicitly setting both and see if the errors continue or change.
  3. Zeebe User Tasks only work with the Zeebe REST API; you cannot do certain operations on Zeebe User Tasks in the Tasklist API. (See docs here.) @Mukesh_Reddy, in your Postman example you are using the Tasklist API when you need to be using the Zeebe API, or switch back to the “classic” user task type. @bpmnenthusiast for your errors, it reads like you may not be using Zeebe User Tasks and are instead using the “classic” user tasks, which need to use the Tasklist API (see the previous doc link in this bullet.)
  4. Multi-tenancy shouldn’t have any bearing on what I’m seeing in this thread, so I think we can safely ignore that as long as the applications/credentials have permission to the proper tenant.

I think there’s a combination of wrong port, wrong endpoint, and wrong API going on, which is leading to a lot of confusion. Hopefully that helps clarify. Give those things a test and report back with what errors are still left unresolved!

Hey @nathan.loding
I have tried with port 8088 still it’s showing same issue and as you mentioned in point no.2 , I have configured it according to that but still it’s showing the same connection exception.

zeebe.client.broker.grpcAddress=http://127.0.0.1:26500

zeebe.client.broker.restAddress=http://0.0.0.0:8080

I have tried other ports mentioned in docker for grpcAddress just in case to check if that’s causing that exception but still it’s showing same error.

ZeebeClient zb = ZeebeClient.newClientBuilder()
		            .grpcAddress(grpcAddress)
		            .restAddress(restAddress).usePlaintext()
		            .credentialsProvider(new CredentialsProvider() {
				        @Override
				        public boolean shouldRetryRequest(StatusCode statusCode) {
				            return false;
				        }
	
				        @Override
				        public void applyCredentials(CredentialsApplier applier) throws IOException {
				            applier.put("Authorization", "Bearer " + accessToken);
				        }
				    })
		            .build();
			zb.newTopologyRequest().send().join();

//			zb.newCompleteCommand(2251799813685589l).variables(variables).send().join();

		
		try {
			zb.newUserTaskCompleteCommand(2251799813685589l).variables(variables).send().get();
			
		} catch (InterruptedException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		} catch (ExecutionException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}

Error :

Caused by: org.apache.hc.client5.http.HttpHostConnectException: Connect to http://0.0.0.0:8080 [/0.0.0.0] failed: Connection refused: getsockopt
	at java.base/sun.nio.ch.Net.pollConnect(Native Method)
	at java.base/sun.nio.ch.Net.pollConnectNow(Net.java:682)
	at java.base/sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:973)
	at org.apache.hc.core5.reactor.InternalConnectChannel.onIOEvent(InternalConnectChannel.java:70)
	at org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
	... 5 more

**For above postman ex zeebe user Tasks I have used zeebe REST API **
source : Complete a user task | Camunda 8 Docs

Hello @nathan.loding ,

many thanks for your prompt response.

To point 3 which addresses the problem I am facing: I am unfortunately already using Zeebe user tasks, and not the job worker implementation.

The reason I suspect multi-tenancy to be the problem in my case is my research in the Zeebe code:

Maybe I am missing some configuration for the tenant, however, the same config works for Zeebe gRPC calls that I am making. Still, let me please describe what the config looks like:

  • I have created tenant A in Identity.
  • I have assigned to this tenant (Tenants → A → Assigned users) a user B, so that B can see the tenant’s data in Operate (this is not really relevant to my problem, but for completeness sake I have described it)
  • Under Tenants → A → Assigned applications I have assigned Tasklist and zeebe.
  • Under Applications → zeebe → Access to APIs I have:
  • Under Applications → Tasklist → Access to APIs I have:

Is perhaps some permission which is specific to the Zeebe REST API missing? Because, as mentioned, the gRPC API can successfully be accessed with tenant A.

Many thanks and kind regards,
bpmnenthusiast

@Mukesh_Reddy - the gRPC port is 26500, the REST API port is 8088. Your config is still using port 8080; I’m confused because you said “I have tried other ports mentioned in docker for grpcAddress” but we weren’t referring to the gRPC port, but rather the REST port. Try this config, and share the results:

zeebe.client.broker.grpcAddress=http://127.0.0.1:26500
zeebe.client.broker.restAddress=http://127.0.0.1:8088

Once you have a successful connection to the server, then we can try to figure out what’s going on with the userTaskKey saying it wasn’t found, but one step at a time to keep it simpler to troubleshoot.

@bpmnenthusiast - just to confirm, when you view the “Tenants” tab for both the Tasklist and Zeebe API clients you took screenshots of, “tenant A” is assigned to those applications?

Hello @nathan.loding ,

yes, under “Applications → zeebe (or alternatively Tasklist) → Tenants”, I see tenant A.

Kind regards,
bpmnenthusiast

@bpmnenthusiast - can you confirm what version of Camunda you are running and how you’re running it (Docker or k8s or other), and can you also share your configuration file (docker-compose, Helm values.yaml, etc.)? It sounds like it should work, assuming the task ID is correct.

@nathan.loding , sure:

I am using the Docker Compose file docker-compose.yaml from GitHub - camunda/camunda-platform: Links to Camunda Platform 8 resources, releases, and local development config. I am using the latest version - 8.5+gen6.

I have changed only the following lines in the .env file which are necessary for Multi-Tenancy:

  • ZEEBE_AUTHENTICATION_MODE=identity
  • MULTI_TENANCY_ENABLED=true

The user task ID should be correct because I fetch it right before that using the query endpoint of Tasklist API and I can see the task in the Tasklist UI.

Hope this helps, I am happy to share more info if necessary.

Many thanks and kind regards,
bpmnenthusiast

Hello @nathan.loding , something I have noticed:

I am using the newest stable version of the ZeebeClient lib:

<dependency>
      <groupId>io.camunda</groupId>
      <artifactId>zeebe-client-java</artifactId>
      <version>8.5.5</version>
 </dependency>

However, the methods that access the Zeebe REST API for user tasks are marked as experimental.

Do you think this can be the reason for the NOT_FOUND error message?

Kind regards,
bpmnenthusiast

@bpmnenthusiast - I haven’t had a chance to test this myself (honestly, it’ll be a couple more days before I can really dig in) … have you tried using Postman (or similar tool) to test the REST endpoint, rather than the Java client? I suspect you’ll get the same error, similar to what Mukesh has, and that means the client isn’t the issue.