Bug Report: Shapr3D Beta Sync between Windows and iOS damages Shapr Cloud file making it inoperable

[heyscott]

Hey guys,
This is my third week of attempting to trouble shoot this bug in Shapr3D beta.
Full disclosure I have development experience extensively in backend and a minor bit of iOS development in my personal history.

Exactly two weeks ago (October 27th) I made an edit on my windows Shapr3D Beta (history) app. As usual this synced to the cloud.

I attempted to open the app on iOS on my iPad a day or two later and instead of popping open like normal there was a brief loading screen “Loading… filename… processing” (see image below), and then the iOS app crashed back to the home screen.

The file was not able to be opened but there was no error message. I reached out to Shapr3D support via email and asked to have a previous version duplicated / restored. In this case file “version 93” (for ease of use, so that I can refer back to it).

Shapr3D restored the file at issue and appended the date to the file name to make it clear which was the duplicated / restored file and which was the original “version 93”.

When attempting to open the restored “version 93_date-restored” file there was no change in app behavior (issue persisted on newly cloned / restored OLDER version of the file); the iOS Shapr3D beta app crashed back to the home after briefly showing the loading screen image shown above.

At this point I thought that probably the issue was related to my user permissions within Shapr3D cloud. I reasoned that since “version 93” was created before the bug occurred, it couldn’t possibly be a corrupted file so on Friday I requested that the originally “version 93” file be dumped to .shapr file.

This morning I was notified that dumping the file will take some time, and I was on my way back into the office to use my Windows installation anyway, so I attempted to open the “version 93” original file on Windows (thinking perhaps there was an issue).

When I opened the Shapr3D windows beta app I was notified there was a new beta version for windows. I asked to download the update BEFORE opening (instead of in the background) and the Beta windows Shapr3D app restarted and then opened showing all my files as normal on my home screen.

The first file I attempted to open was the “version 93” file that had been inoperable for two weeks.

The file DID NOT open but DID (on the new Windows version) throw an error showing the the file was damaged and couldn’t be opened with text “Import Failed: Your source file couldn’t be loaded because it is damaged.” , see image:

The “version 93” file has never left the Shapr3D cloud, therefore any damage was caused by one of:

• Shapr3D Beta (Windows)
• Shapr3D Beta (iOS)
• the Shapr3D Beta cloud backend

Next I attempted to open the restored version which had been cloned by Shapr3D support with the date code appended “version 93_datecode”. The same exact error screen was shown.

After that I attempted to open another file, which HAD been working this morning on Shapr3D Beta iOS on my iPad, lets call this one “File 2”. I got the same message: “Import Failed: Your source file couldn’t be loaded because it is damaged.”

At this point I went to my iPad and attempted to open “File 2”.
The bugged behavior now replicated on the iPad / iOS Shapr3D Beta for “File 2” and that file was in-accessible.

Remembering that I had just updated Windows Shapr3D Beta, I closed Shapr3D Beta iOS and checked TestFlight: YES there was a new version. I updated the Shapr3D Beta from TestFlight to the latest version and attempted to open “File 2” - the behavior persisted.

So.
At this point I have three files which can’t be opened:

• Version 93 (original File 1 that had issue on October 28th or 29th)
• Version 93_DateCode (restored by support)
• FIle 2 (just became in-operable today)

I am relaying this information to support but I am also posting the forum to save a future user who encounters this bug on Beta some time, and to see if anyone else knows of a workaround not yet suggested by support.

I will update here if I find a solution or get one from Support.

[heyscott]

After describing the above issue to support with approximately the same language written in my last post, support has suggested restoring a previous “version 76” of “File 2” that just became in-operable.

Based on previous experience which the same support rep worked through with me it is exceedingly likely that any sort of restore via copying a previous version will not solve this problem because the File version stamp (which is applied internally within the Shapr3D cloud) does not match whatever local cache version stamp exists and the file is effectively orphaned in the version history for that reason.

Support indicated that the full release of the History Beta should fix this issue. I find that unlikely as I have three orphaned files (within Shapr3D cloud) which are getting further out of date and may actually stop being compatible with the presently released version at some point. Waiting for a future release to “maybe” fix this issue is not responsible unless we know for a fact that this bug is listed for work, is known by the development team, and has a tested fix which is set to be deployed in that specific version.

Yes. I could have exported a .shapr file at any point which would allow me to re-import safely (which is the only way I am still actually progressing on my project) I am now doing that consistently and do not expect to make the same mistake a 3rd time.

My goal here is to make sure this bug is logged with development so that we can all be sure that it does not release into the wild with the release of Shapr3D history beta. I am also hoping that anyone else who hits this bug will be saved time and that support will also be saved that same amount of time when determining the issue.

At this point I have been discussing the issue for at least two weeks with support via a single email thread.

I have done enough trouble shooting to determine almost EXACTLY what the problem is, and still there is no offer to escalate this to someone on the development team who… probably… could simply edit the version number within the backend Shapr3D cloud database to make it match my local cached version number (the up to date version of Shapr3D Beta), at which point all of this would almost certainly go away.

My assumption right now is that the file version IS NOT damaged since the “new” mis-matched app was never able to open it to begin with, and because the preview image of the files is accurate as expected. Therefore my belief is that only a version number flag has been updated (possibly within my own local cache, possibly on the Shapr3D Beta backend) which now causes a mismatch between the local cache and the Shapr3D cloud database. The app then sees this mismatch (or some such issue) and refuses to open the file because it is damaged.

This renders the files (there are now three, including one restored by support which also does not work) in operable, and since the files are effectively orphaned from all updates there is now a growing risk that these files will no longer work with any future version and actually may be damaged beyond repair.

Thankfully I only have about 6-12 engineering hours into these projects, and I chose projects that I would be “more comfortable” having issues with to play with the Beta, but still I would love to get those 12 hours of my life back at some point.

Another possibility is that the “edited” version stamp is applied IMMEDIATELY on opening a file. This could cause the most recent version (which has not had data populated) to trigger a version mis-match when comparing / attempting to import data from the previously edited (correct) file version within Shapr3D cloud - this would make sense if there is a lot of late hydration of data to improve user experience. I am not sure that checks out since in that case restoring an older version SHOULD result in everything working, but its another avenue to explore as far as a solution.

The bug has now been verified in the last TWO version updates and I have created a sacrificial test file which I will use to replicate this bug again on the next update / future version.

I will post back with updates and communications.
Any workarounds are appreciated.

[heyscott]

To update after more testing, continued communication, and a fourth occurrence of the damaging of a file and then the SYNCing of that “damaged” file from Windows to all devices making it inoperable across all platforms.

I ran into the same behavior described above last night when the Shapr3D Beta versions correctly matched the latest on my iOS iPad and Windows PC (ie. all apps up to date on latest version).

There are two big results here:

1. Mismatched versions MAY be one way to achieve the initial “Damaged” file status, but there is at least one other unknown but which causes Windows to believe a file was damaged when last editing on iOS (I am not sure why the above scenario resulted in that damage but no app was updated, windows still believed the file was damaged).

2. When the Windows App, and maybe all apps, OPEN a file the app believes is damaged, this opening action counts as a change and SYNCS the damage status of that file to the server.

This is due to declaring the “OPEN” action on a device as a “Change” to the file even if the device fails to open that file due to damage. That “change action” is then uploaded to the cloud in the version history. Opening a file and making no changes should not necessarily require a sync, and specifically the sync SHOULD NOT occur before the app is SURE the file has opened without damage… but both the iOS and Windows apps appear to do this.

So it is this sync, and specifically a SYNC even though the App opening the file believes it is damaged, which is part of this bug… since sync’ing the damaged file is how the file on the SERVER gets corrupted and how all other devices then end up believing the file is damaged making it inoperable on all platforms.

AT WHICH POINT the server disseminates the “Damaged file flag” which then no longer allows ANY app to open the file, even though the iOS device I was using was happily editing the identical file… after the server “syncs” the file which Windows thought was damaged it no longer opens.

3. The “Import Failed -Your source file couldn’t be loaded because it is damaged.” error pop up fails to pop up when opening a “file damaged during sync” on iOS. This is a separate bug but may give a small clue.

[edgarandriasyan]

Thanks for your feedback. We have diagnosed the issue and are working on a fix. Our support team is in contact with you and will update you with further details.

[heyscott]

Update:
THIS IS NOT A SYNC ISSUE.

Support was able to fix one of the files that had been corrupted by actions that I took from my iPad.

My guess at this point is that deleting a pattern from History timeline caused orphaned items to still appear in the “Items” list. Attempting to Delete those orphaned (shouldn’t exist) items then caused the file to be Damaged… but still work on the device on which the damaged occurred (iOS, prior to sync)

Sync’ing sent the damaged file through to the S3D cloud and then down to my Windows machine where the Windows Beta app correctly noticed the damage.

When the windows app noticed the damage this data some action occurred on the cloud side indicating the damage such that when the iOS device went to re-open the file the S3D beta iOS app also crashed noting the damage. Due to a small bug the the notification / pop up box on the iOS version of the S3D beta did not pop to indicate the file was damaged.

Regardless the key file for my project has been restored and I will continue to work with support to understand what actions I took (Pattern deletion from history timeline?) may have contributed.

Importantly there is no Sync issue so far as support, or I, can tell.