# Long polling inside workflows or activities
**URL:** https://community.temporal.io/t/long-polling-inside-workflows-or-activities/11348
**Category:** Community Support
**Tags:** polling
**Created:** [March 13, 2024, 4:39am UTC](https://community.temporal.io/t/long-polling-inside-workflows-or-activities/11348 "2024-03-13T04:39:01Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@arthurv](https://community.temporal.io/u/arthurv)
#### Post date: [March 13, 2024, 4:39am UTC](https://community.temporal.io/t/long-polling-inside-workflows-or-activities/11348/1 "2024-03-13T04:39:01Z")
So we have an order use-case and an external system is expected to process payment, the customer has X days to settle payment using the external system (the amount varies by types from 2-0 days)
during this time the order status is Pending-Payment …
I was planning to create a workflow that will poll the internal system every hour or 30 min maybe even some exp. backoff config that will identify if the payment was made and if so move the Order into Approved status.
I cannot make the activity poll because then the worker will be busy forever and its illogical to idle the worker for such a long time also I believe setting such a long timeout is not practical
Creating a workflow that will poll in a loop using an activity will possibly create a huge workflow event history and might exceed the limit…
In addition I’m not sure it falls into the deterministic constraints requirement because some executions will have 3 polls until completed and other will have 300 …
Would love to hear any feedback or direction for implementing this.
---
### Author:  [@maxim](https://community.temporal.io/u/maxim)
#### Post date: [March 13, 2024, 5:11am UTC](https://community.temporal.io/t/long-polling-inside-workflows-or-activities/11348/2 "2024-03-13T05:11:18Z")
> [@What is the best practice for a polling activity?](https://community.temporal.io/t/what-is-the-best-practice-for-a-polling-activity/328/2):
>
> It depends on how frequently you want to poll. For infrequent polls (every minute or slower) use the server side retry. Specify a [RetryPolicy](https://github.com/uber-go/cadence-client/blob/c3cd9f8f9745172572659a28ad1b478c19596def/internal/activity.go#L107) (or [RetryOptions](https://github.com/uber/cadence-java-client/blob/1b2a2ce0de2bc92a609080186009dd793920b46c/src/main/java/com/uber/cadence/activity/ActivityOptions.java#L141) for Java) when invoking the activity. In the RetryPolicy specify an exponential coefficient of 1 and an initial interval of the poll frequency. Then fail the activity in case the polled resource is not ready and the server is going to retry it up to the specified retry policy expiration interval. So what you are doing is absolutely OK. …
---
### Author:  [@arthurv](https://community.temporal.io/u/arthurv)
#### Post date: [March 13, 2024, 5:53am UTC](https://community.temporal.io/t/long-polling-inside-workflows-or-activities/11348/3 "2024-03-13T05:53:46Z")
Thanks for the quick reply …
So I was thinking of utilizing retry policy for that … the thing I didn’t like that the workflow will display failures of activity when the poll was an actual success and there is no simple way to distinguish between an actual failure to poll (due to conn err or config issue) vs a successful poll with a negative answer …
---
### Author:  [@arthurv](https://community.temporal.io/u/arthurv)
#### Post date: [March 22, 2024, 5:44am UTC](https://community.temporal.io/t/long-polling-inside-workflows-or-activities/11348/4 "2024-03-22T05:44:12Z")
There is another issue @maxim with this approach.
After poll timeout is reached and the payment has not been fulfilled there is some cleanup work to be done (remove the payment request)
to achieve this with retries i will have to have some code knowing how many retries to expect and if its the last one i will issue a call to another workflow to verify that payment request was remove …
all this does not seem elegant …
from the determinism approach, can i invoke an activity in a loop a different amount of time with workflow.sleep(…) between iterations ?
i know the history might be big … but ill make sure to have the poll to be set and validated for a reasonabla amount of retries … no more than 50 i think …
---
### Author:  [@maxim](https://community.temporal.io/u/maxim)
#### Post date: [March 22, 2024, 5:49pm UTC](https://community.temporal.io/t/long-polling-inside-workflows-or-activities/11348/5 "2024-03-22T17:49:45Z")
Sorry, I don’t understand your concerns. After poll timeout is reached the activity will complete/timeout and the workflow can execute whatever cleanup logic is needed. What is not elegant about performing the cleanup logic in a finally block?
---
### Author:  [@arthurv](https://community.temporal.io/u/arthurv)
#### Post date: [March 22, 2024, 6:19pm UTC](https://community.temporal.io/t/long-polling-inside-workflows-or-activities/11348/6 "2024-03-22T18:19:25Z")
Ha, sorry it is I who didn’t understood what you meant …
We wrapped the sdk with a generic Simple workflow of a single activity … what you mean is I create a workflow with 2 activities one for polling with retries … and then based on its outcome another activity with cleanup logic.
Thanks . Yest that will work … will have to create a new wrapper then 🙂 …
In our project we decided not to openly let writing of complex workflows, we create dedicated wrappers for common scenarios… so this will be an implementation of a polling workflow with pre, poll and post activity …
Thanks for the help !
---
### Author:  [@maxim](https://community.temporal.io/u/maxim)
#### Post date: [March 22, 2024, 6:39pm UTC](https://community.temporal.io/t/long-polling-inside-workflows-or-activities/11348/7 "2024-03-22T18:39:28Z")
I would advise against such a wrapping. It sounds like a good idea, but it just eliminates 90% of Temporal value without much benefit.
---
### Author:  [@arthurv](https://community.temporal.io/u/arthurv)
#### Post date: [March 22, 2024, 6:49pm UTC](https://community.temporal.io/t/long-polling-inside-workflows-or-activities/11348/8 "2024-03-22T18:49:00Z")
I agree that it eliminate most of temporal capabilities …
But this is exactly my goal. Make it hard to do complex things and stick to known patterns …
At least for the beginning of temporal integration into our codebase.
There are 3 scenarios we support …
1. Simple single activity workflow to be executed
2. Scheduled Cron like job
3. And now a polling workflow …
As we dive deeper into implementation we will consider opening up more flexibility …
Main concern is code maintenability
---
### Author:  [@maxim](https://community.temporal.io/u/maxim)
#### Post date: [March 22, 2024, 6:55pm UTC](https://community.temporal.io/t/long-polling-inside-workflows-or-activities/11348/9 "2024-03-22T18:55:53Z")
The main goal of Temporal is to eliminate the need for “known patterns,” as all these patterns are extremely leaky abstractions. The code maintainability of a 100% Temporal solution is much higher than that of any EDA-based system.
I’m talking from my experience with many teams that introduced Temporal. The teams that tried to hide Temporal from developers were the most unhappy ones in the long term. The exception is when the end users are not developers; then, a DSL-based solution makes sense.