# Best practice for handling lost external events and resuming paused workflows

**URL:** <https://community.temporal.io/t/best-practice-for-handling-lost-external-events-and-resuming-paused-workflows/18647>\
**Category:** Community Support\
**Tags:** java-sdk, polling\
**Created:** [November 10, 2025, 8:04am UTC](https://community.temporal.io/t/best-practice-for-handling-lost-external-events-and-resuming-paused-workflows/18647 "2025-11-10T08:04:40Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![Abhinav\_Verma](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/abhinav_verma/32/4887_2.png) [@Abhinav\_Verma](https://community.temporal.io/u/Abhinav_Verma)\
**Post date:** [November 11, 2025, 2:47pm UTC](https://community.temporal.io/t/best-practice-for-handling-lost-external-events-and-resuming-paused-workflows/18647/7 "2025-11-11T14:47:29Z")

</div>

Thanks @antonio.perez . I’m implementing **periodic polling** as a **child workflow** , which will be triggered by the parent workflow.

In the official Temporal Java samples, the polling logic is implemented directly inside the workflow code. However, that is not a good practice [Polling in workflow vs. Activity? - #2 by maxim](https://community.temporal.io/t/polling-in-workflow-vs-activity/453/2).

Since in my design the polling runs inside a **child workflow** , and the **parent workflow only records the start and end events** , am I correct in assuming that this approach won’t negatively impact the parent workflow’s history size or performance?

---

_[View the full topic](https://community.temporal.io/t/best-practice-for-handling-lost-external-events-and-resuming-paused-workflows/18647)._