# Sync table with the 60 s timeout **URL:** \ **Category:** Making Packs\ **Created:** [January 27, 2022, 10:17pm UTC](https://connect.superhuman.com/t/sync-table-with-the-60-s-timeout/28498 "2022-01-27T22:17:07Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![j.b\_o](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/j.b_o/32/20739_2.png) [@j.b\_o](https://connect.superhuman.com/u/j.b_o)\ **Post date:** [January 27, 2022, 10:17pm UTC](https://connect.superhuman.com/t/sync-table-with-the-60-s-timeout/28498/1 "2022-01-27T22:17:07Z")
Hello, For a sync table, i get a dozen of item then for each item i make an additional request to fetch the image and get a temporary url with the temporaryBlobStorage property (see [here](https://connect.superhuman.com/t/queryparamtoken-access-to-the-parameter/28310/5)). Unfortunately, i face to an error because the sync formula timeout after 60 seconds : `Unhandled: {"errorMessage":"2022-01-xxx Task timed out after 60.06 seconds"}` I read into the [doc](https://coda.io/packs/build/latest/guides/blocks/sync-tables/#longrunning) that : > Continuations are not designed for persisting large amounts of data between executions So is there a better approach than the continuation? I have another use case with several item with their image, could it be consider as a large amount of data? Thank you in advance for the thoughts. ---
**Author:** ![Eric\_Koleda](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/eric_koleda/32/50286_2.png) [@Eric\_Koleda](https://connect.superhuman.com/u/Eric_Koleda)\ **Post date:** [January 27, 2022, 10:49pm UTC](https://connect.superhuman.com/t/sync-table-with-the-60-s-timeout/28498/2 "2022-01-27T22:49:44Z")
In these cases we recommend that you re-fetch the full list of items at the start of each sync execution, and then keep track of where you are in that list using an index. You can see an example of that approach in the [Spell sample](https://coda.io/packs/build/latest/samples/topic/sync-table/#with-continuation). Because the fetcher caches responses, re-fetching the full list should be fast. ---
**Author:** ![j.b\_o](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/j.b_o/32/20739_2.png) [@j.b\_o](https://connect.superhuman.com/u/j.b_o)\ **Post date:** [January 28, 2022, 9:54pm UTC](https://connect.superhuman.com/t/sync-table-with-the-60-s-timeout/28498/3 "2022-01-28T21:54:51Z")
Thank you @Eric_Koleda for your answer. In Dungeons and Dragons’ example, it uses a batch variable. But the variable doesn’t guarantee the respect of the 60s timeout. The server answer could change, couldn’t it? ---
**Author:** ![Eric\_Koleda](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/eric_koleda/32/50286_2.png) [@Eric\_Koleda](https://connect.superhuman.com/u/Eric_Koleda)\ **Post date:** [January 29, 2022, 2:05am UTC](https://connect.superhuman.com/t/sync-table-with-the-60-s-timeout/28498/4 "2022-01-29T02:05:30Z")
Yes, that’s a good point. That batch size works with the speed of the API today, but may not if for example the API gets significantly slower. I’d recommend testing out various batch sizes and look for a value that complete well under 60 seconds, to leave room for fluctuations. ---
**Author:** ![j.b\_o](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/j.b_o/32/20739_2.png) [@j.b\_o](https://connect.superhuman.com/u/j.b_o)\ **Post date:** [January 29, 2022, 7:51pm UTC](https://connect.superhuman.com/t/sync-table-with-the-60-s-timeout/28498/5 "2022-01-29T19:51:13Z")
THank you @Eric_Koleda . ---
**Author:** ![system](https://yyz1.discourse-cdn.com/coda1/user_avatar/connect.superhuman.com/system/32/24484_2.png) [@system](https://connect.superhuman.com/u/system)\ **Post date:** [February 1, 2022, 7:52pm UTC](https://connect.superhuman.com/t/sync-table-with-the-60-s-timeout/28498/6 "2022-02-01T19:52:03Z")
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.