Ride save/exit process is frail and if disrupted there is zero recourse

In theory, Zwift has a good strategy for handling complexities related to online users need to stream data where streams may be disrupted (ex. wifi drops) without losing data. During rides, the activity data is generated on our local computers and synched up frequently, which is why at the end of a ride you’ll notice in the activities folder a date/time stamped file for the entire ride, plus a similar “inProgresActivity.fit” file that’s the file used to buffer during the ride between the local computer and Zwift.

If you’ve ever noticed, for example, periods where everyone else in Zwift disappears and you’re on the road alone, that’s an indication that the stream has dropped, and the fact that I can still ride until it’s restored (up to 10 minute limit, roughly) without losing all progress or having to restart is a much appreciated error-handling design feature.

When saving/exiting, I believe the general sequence of events is that there’s a basic log out type of action where the inProgressActivity is closed out, copied to a date/time specific .fit file on the local machine, then sent up to Zwift for a chain of actions. Depending on the ride, your online activity history gets a new record, your profile cumulative totals are updated, any in-ride achievements or unlocks are processed, and any external integrations to other partners (zwiftpower, strava, etc.) are sent out. This is usually a pretty quick process, but it seems if there are any hiccups along the way, it will abort however far along it got and that’s the end of that, no recourse. For example, I’ve seen cases where my ride shows up in activity, but completion of the workout (ex. LeTour challenge) is not credited or counter towards badges like Alpe du Zwift or Volcano climb are not updated.

The support FAQ and multiple support case/tickets have all responded to these type of issues along the lines of “due to technical limitations, we can’t update that”, even if it’s something as minimal as unlocking a jersey or awarding a badge. This is despite the fact that I’ve provided a valid (NOT CORRUPT) .fit file for the entire activity. There just doesn’t seem to be any way for a user or Zwift employee to upload or “reprocess” any ride that did not successfully make it through the save/exit process.

In my opinion, with the rapid growth of Zwift user base and level of participation, this frail logout/save/exit process is going to grow from occasional nuisance to more frequent problem and should be addressed. There needs to be much better error handling within that sequence, or at the very least the support team needs access to tools to manually edit/update commonly affected data when a user provides clear evidence of what failed to update.

Hi Chan, i would agree that an upload mechanism would be a great potential fix for the vulnerable saving process. I started a feature request thread a week or so ago for essentially the same thing if you’d like to upvote it: Ability to replace incomplete zwift .fit file with full local version

@Gordon_Winchester thanks. I wasn’t sure whether this would be a bug or feature, figured I’d start the argument for bug to elevate the priority. I agree your feature description is what I’m describing and have up-voted your request.

It is a bit ridiculous that you can complete a 2 hour ride perfectly fine, but if your internet drops at the point of "Save"ing it, then you are screwed.

You can hack around, email the files to yourself to get them on Strava, etc. but not Zwift itself, which is really poorly thought out. It seems like they did 90% of the work to have a robust system, then couldn’t be bothered to finish it.