How to guarantee proper results on "GetSheet" API after "UpdateSheet" API"?

Imagine a gantt-style Project sheet with many tasks on it. That sheet was created with a particular work schedule (days of week, and hours per day) and a particular holiday schedule.

Now use the UpdateSheet API call to update the sheet and change the work schedule and/or holiday schedule.

This will cause cascading changes in many (possibly even all!) end dates on tasks, and if there is any complex predecessor tasks will further cause cascading changes.

QUESTION: Will all those changes happen in the sheet synchronously before the response to the UpdateSheet API is sent? In other words, if you do a GetSheet API call immediately after the UpdateSheet that changed the schedule, are you guaranteed that the start and end dates are all properly changed in all the tasks on the sheet, even for an arbitrarily large sheet? Or will that cascade of changes happen asynchronously, and if so, how do you know when it is done so you can invoke the GetSheet API and be guaranteed that all the tasks have the start and end dates set appropriately?

SIMILAR QUESTION: On a sheet with a complex predecessor hierarchy, changing dates or durations on one row may cause substantial cascading changes through the sheet. If you use the UpdateRow API to change the dates or duration of a row, and immediately following you call the GetSheet API, are you guaranteed that ALL the rows on the sheet will have the proper dates and duration based on the changed predecessor hiearchy?

Find more posts tagged with

Accepted answers

Genevieve P.

Hi @sgolux

Yes - while step 7 should immediately return all correct dates if step 6 is confirmed to be completed successfully, I would still recommend building a 60-second delay between those two steps to guarantee this.

If you're able to reproduce what you saw before, please do share any recordings or examples that show incorrect dates with step 7 with the Support team so they can troubleshoot this with you! There may be additional complexities specific to your set-up and process that may cause delays that are not documented and the Support team can help get to the bottom of that.

Cheers,

Genevieve

All comments

Genevieve P.

Hi @sgolux

The changes to dependent rows will happen at the same time as the update to the cells, meaning that if you wait until the Update is successful, then using a GetSheet after should return the correct, new result.

For example, I updated a Start Date for a Predecessor using the API, and as it updated the affected rows within the same "save", highlighted in blue as they are updated by that same API call:

If you want to be absolutely certain, I would give it a 60-second buffer time just to be on the safe side. See more "best practice" notes in the API Documentation under "Working at Scale", here: https://smartsheet.redoc.ly/#section/Work-at-Scale/Rate-Limiting

Cheers,

Genevieve

sgolux

Thanks @Genevieve P. -

I do appreciate the insights, and I did re-read the best practices in the Working At Scale document you shared and I don't think I am in any violation, in rule or in spirit.

I do think, however, that while I cannot duplicate it reliably, it SEEMS I have encountered the situation where I update the holidays on a sheet with the UPDATE SHEET API, and wait appropriately for that request to complete, and then immediately call the GET SHEET API in order to get all the new task start and end dates, which would be re-populated as a result of that change in holidays, and it seems that sometimes I am getting rows that do not have those updates completed on very large sheets, especially those in the hundreds of rows scale. I will try to create a reliable duplicatable test case for this.

Steps in my synchronize operation go like this:

Get the project details as represented my local system
Call the GET SHEET API to get the current state of the Smartsheet representation of the project, and wait for it to return.
Compare the holidays from the local representation to the Smartsheet representation.
If they are the same, drop out of this sequence (not important for this issue.)
If we get here, locally represented holidays (source of truth) are different than Smartsheet represented holidays.
Use the UPDATE SHEET API to update the Smartsheet understanding of the holidays to match the local representation. Wait for it to complete.
Call the GETSHEET API again to get the new current state of the Smartsheet representation with new start and end dates on tasks. Wait for it to complete.
Smartsheet is the source of truth for tasks, so iterate through the rows and update the local representation of tasks from the Smartsheet now-correctly-dated-based-on-holidays tasks.

Waiting 60 seconds between steps 6 and 7 would be really painful and make our synchronization slow..... I think I understand you to say that when we call GET SHEET in #7, we should be guaranteed correct dates on the tasks even if the sheet itself is very large. In other words, #6 should not return until all changes to all rows are complete.

If I can find a reproducible counter-example (and I will try!) I will share it with you.

But if you can share my algorithm and concerns and belief that there is an occasional but not reproducible hiccup as I have described above with your engineering team, and let me know if they think this is just impossible and I must be on drugs or doing something wrong, I would appreciate that feedback!

Thanks again,

-stephan

Genevieve P.

Hi @sgolux

Cheers,

Genevieve

Sign in to join the conversation!

Quick Links

Component react.discussion.discussions had an error.

ref must be one of: categoryID, siteSectionID, category, category/categoryID, category/name, category/description, category/url, category/allowedDiscussionTypes, locale, siteSection, siteSection/basePath, siteSection/contentLocale, siteSection/sectionGroup, siteSection/sectionID, siteSection/name, siteSection/description, siteSection/apps, siteSection/attributes, layoutViewType, discussionID, commentID, page, sort, sortType, lookupSort, discussion, discussion/name, tags, breadcrumbs, discussionApiParams, serverDraftID, serverDraft.