When the CopySheet API responds, is the copied sheet really fully created?

I am synchronously using the CopySheet API to make a copy of a sheet. This API responds with a sheet summary, which itself includes the copied sheet's id. Immediately when that sheet is copied, I call the GetSheet API to get the full details of the new sheet. Mostly this works, but a moderate number of times, I will get a 404 Not Found response to my invocation of the GetSheet API, indicating that the sheet is not fully baked or not fully available yet, or perhaps there is some caching of sheets available on the Smartsheet side and the cache isn't busted? It is very odd behavior. Is this expected?

Find more posts tagged with

API and Developers

Sheet Summary

copy

Accepted answers

All comments

Brian_Richardson

I get that too…not sure if it's expected. My only guess is that there's a small delay between the sheet creation and the insertion of that sheet ID into whatever lookup db the API uses to find sheets by ID. I see similar behavior in Search also, where very recently created sheets simply don't show up for a minute or two in search results.

I started inserting a 30s delay in my workflows that rely on Copy Sheet and then want to do something with that sheet. I don't know if that's enough, so far so good but I only started making that update a week ago for the same issue.

Alex Argumedo

This is even worse when deleting sheets or folders, the backend needs an even longer wait, if you delete a parent of an element that is still in the deletion process in the backend, the element ends up orphan and you will get some serious issues later down the road. So yes, even if you get a positive response the backend requires time or even better don't take any action until you get a response with a new get, when you are going to take tasks that affect the same element.

sgolux

Ooof. Thanks @Brian_Richardson - helpful to hear this. Also sobering. The nature of my integration will not allow a wait for anything like 30 seconds. I'm going to put in a delay of 500ms and see if that helps my situation. My opinion…. I would call this a bug. If Smartsheet really needs for some reason to do some work asynchronously after responding to the request, it should at least respond with some kind of specific "Not Ready Yet" error, ideally with a header telling us an estimate for how long to wait. Thanks also @Alex Argumedo for your insights.

For now I will not mark this "Answered" in hopes that a Smartsheet engineer will weigh in with some additional detail.

Brian_Richardson

If you want Smartsheet to weigh in then I'd open a ticket for it. Although Genevieve does peruse the forum and offer a LOT of help, I don't often see other Smartsheet staff on here.

Brian_Richardson

I'm also going to just give my 2c here though - yes it's annoying that it seems to be asynch and I totally agree with you on getting appropriate messaging. It's frustrating not to now. But on the other hand, devil's advocate, I don't think they designed the backend to respond instantly to sheet copies as part of an urgently timed workflow.

We might see this improve when the new backend rolls out, which is supposed to be relatively soon (hopefully) as they announced it almost a year ago.

sgolux

I have filed a ticket. If/when anything useful shows up there, I will post here as well.

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, discussion, discussion/name, tags, breadcrumbs, discussionApiParams, serverDraftID, serverDraft.