Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to use Zeebe client in its existing state for Lambdas on AWS #637

Open
rakeshroberts opened this issue Jan 21, 2024 · 2 comments
Open
Assignees
Labels
bug Something isn't working

Comments

@rakeshroberts
Copy link

Describe the bug

When using the ZeeBe client on a lambda, the code uses the presence of the a directory or the ability to create the directory, and a dictionary of a token file.

This is not possible when using the native .net execution on an AWS lambda.

To Reproduce
Steps to reproduce the behavior:

  1. Create a lambda in an AWS account with enough code to connect to a valid Camunda process
  2. deploy the code to an AWS lambda (do not use a container).
  3. trigger the lambda
  4. The Lambda will fail. and then error will indicate the inability to create

The culprit is here
https://github.com/camunda-community-hub/zeebe-client-csharp/blob/main/Client/Impl/Misc/PersistedAccessTokenCache.cs#L28

Expected behavior
What should happen is the AWS lambdas should be able to connect to ZeeBe client without relying on a directory or a dictionary stored on a file system that is not guaranteed to exist.

Alternate options are

  • Use memory
  • Use Cache
  • Use S3 stores
    With the ability to use them if they are configured. also let the customer chose the token storage provider, with their own custom code.

Enviroment (please complete the following information):

  • AWS
  • AWS Lambda Executors for .net 6
  • Any version of the ZeeBe client

Additional context
Add any other context about the problem here.

@rakeshroberts rakeshroberts added the bug Something isn't working label Jan 21, 2024
@ShawnAbshire
Copy link
Contributor

Fix for this would be configuring the access token path, addressed in the feature request #636, to write to the /tmp directory.

@rakeshroberts
Copy link
Author

A better fix for this would be allowing the cloud builder to specify the location of the temporary storage.
The flip side of this, is that write access to the tmp directory maybe ok, but you're not guaranteed to grab the same /tmp directory for this.

  • A better fix for this would be allowing the camunda client builder to have a strategy of choosing memory as a location for the cache storage or setting it to a cache location or letting client specify the storage location and mechanism while building this out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants