Bug: Workout "portals" respawn/redraw at incorrect locations (wrong routes, and random locations)

(I don’t have a screenshot of this one yet since by its nature it is extremely intermittent and transient and hard to capture. I would need to video an entire ride somehow to catch it occurring and I don’t have a setup to do that personally. I will keep trying to capture screenshots of these issues, but its almost impossible given how transient the first in particular is)

When you are in a workout, you have one or more “segments” or intervals that have a defined power and duration. When in a workout with multiple segments, the transition from one to the next is marked by a glowing semi-translucent “portal” on the road ahead of you, coloured (in theory) in tune with the zone that the next upcoming segment is in. I don’t know how far up the road the segments are drawn/displayed but its enough to prepare for the next zone transition. (As far as I know, only the next segment is marked by a portal and that a portal isn’t drawn at the start for *all upcoming segments). So far, this is all correct behaviour.

However, there are two bugs with the location that the portals spawn in:

  1. When approaching a junction, if the time to junction is less than the time remaining in the current interval, then the portal has to spawn after the junction (obviously). However the logic used to calculate on which “branch” ahead of you to spawn the portal is flawed/faulty. Specifically, it does not seem to always lie on the route that you are currently riding. For example, if you are riding the Volcano Flat route, your avatar will steer right at a given junction as part of the route navigation. You will also receive an on-screen road-sign showing the junction options and your route’s chosen path (right, in this instance) will be highlighted in a red border. However, an upcoming portal will often be drawn ahead of you on the left (incorrect) fork, or vice versa. Whatever logic is used for the portal’s route mapping/draw location is divorced from your avatar’s current route, and hence wrong (or wrong as often as it is right). FIX: make the workout portal spawning logic route-aware and tied to your rider’s current active route, not use some default logic for junction/route selection.

  2. When workout portals spawn, you would expect their location on the road to remain relatively constant. If your speed increases due to an incline the portal may gradually draw nearer to you, the same thing if your power drops, since it will take you longer to reach a given point on the route. So far, so good (and expected). However, intermittently and on some routes (Watopia around the marina and approaching the volcano seems particularly susceptible?) the portal will flicker into existence in completely the wrong place (say, 6 foot ahead of you) for far less than a second before redrawing almost immediately in the distance at the “correct” distance. I have no idea what’s causing this. It is highly intermittent and seems to occur on some routes more than others.

EDIT: just to add the suggested info from the “Guide to Getting useful Support” pinned thread:

  • Platform - 12.9" Apple iPad Pro
  • OS - iPadOS
  • Zwift version - 1.32.0
  • Trainer - Wahoo Kickr (v6)

Don’t think you need to worry about screenshots. Those two things have been happening since workouts were first introduced so I’d think Zwift is aware.

1 Like

Why is it every time I report a bug the situation seems to be “oh yes, Zwift have known for years… they just haven’t fixed it” :frowning:

Thanks for the reply @B_Jimmy , I did do a search but didn’t find anything, do yuo know the existing ticket ref/bug report link please? :slight_smile:

1 Like

:rofl: :rofl: :rofl:

1 Like

FWIW: The next portal is ‘drawn’ at the lesser of 2 minutes remaining in the current interval or the start of the current interval (i.e. if the interval is 1 minute the next portal will be drawn immediately). As for the logic at forks, I am not exactly sure of the logic used but the reality is that you could go either direction at the fork. So, it may just be picking the ‘most likely’ or something like that. So it’s not really in the ‘wrong’ place, it’s just not in the place you are going, but you could opt to if you wanted. I’m not going to say the logic couldn’t, or shouldn’t, be changed, just that you do have the option of going through the portal as originally drawn, but have opted to go a different direction. At least the game figures it out before you actually get to it (though this can be a bit unnerving if your interval is ending right at after an intersection!).


Oh come on Nigel, you’re often the voice of reason but I don’t agree with you there at all. Your avatar is on a set course/route unless you choose to diverge from it. Everything apart from workout portals agrees with that - the route sign, the direction your avatar takes when they reach the turn, even the flashing indicators on your bike.

Zwift “knows” what route you’re on and all other elements respect this. We don’t expect the indicators/turn signals to flash right just because you could choose to turn right when you’re on a route that’s going to steer you left do we :rofl:

This is definitely a fault, I’m not having you pass this one off as an acceptable design decision :wink:

I think the logic might just be built into the game, not into the route you have chosen. I have noted, for example, that when I am doing a workout on a route that will take me from Downtown Watopia onto Ocean Blvd the portal will always appear somewhere in the Hilly Route KOM. My thought has been that this is because the Hilly Route existed before Ocean Blvd, so the logic was only changed to add in something along the lines of ‘if the rider doesn’t end going up the Hilly Route KOM then move the portal’. I don’t think anything was ever changed to ‘take a look at what route the rider has chosen and put the portal along that route, and then move the portal if the rider chooses a different option at the intersection’.

I think this is just one of the many examples of ‘spaghetti code’ that users refer to, where the game coding has been been added to, instead of modified, as the game has developed.

That makes perfect sense in terms of the origin of the wrongness @Nigel_Tufnel agreed :slight_smile: Doesn’t make it any less wrong :stuck_out_tongue:

Yeah, I’d guess it’s the same as with the gradient profile, that both that and the portals end up in some default direction regardless of route and only get corrected once it truly is too late to go that way. It is almost as if the only part of the code that knows which way you are going is the one that actually decides which way to turn when it is time for that (and even that one does go the wrong way without user intervention every now and then).

I had this again yesterday, this time on the “Richmond” map. It seemed worse/more frequent on that route for some reason than on others. At time the workout portal was flickering around extremely quickly (microsends) almost like a strobe effect, redrawing at say 50m, 100m, 150m, 10m, 200m, 50m from my avatar in lightning-fast succession before settling on the correct distance eventually. It honestly was like a strobe effect it was redrawing (in the wrong place) so often and so quickly. I suspect it could (in all seriousness) cause problems for people who suffer from epilepsy.

I don’t see any acknowledgement of this bug from Zwift so far. Have you seen this one please @shooj ?

@shooj (or anyonne else from Zwift support) can you confirm if you are aware of this bug please as an existing issue? (I couldn’t see it listed in “known issues” but I may have missed it - apologies if so). If its not already logged/known, can you log this please and provide a ticket reference?

Thanks :slight_smile:

I rode in the “France” map today, “Douce France” route, and this problem was occuring maybe once every 3 intervals on average so I took time trying to spot a pattern and the information from @Nigel_Tufnel above is key - the “random/wrong spawn” was happening at the 2 minutes until end of interval mark - the portal would consistently spawn maybe 10-20m in front of my avatar (ride time maybe 2-5 seconds) befor realising it was in completely the wrong place and redrawing in the far distance (i.e. 2 minutes away).

What was interesting about the France map is that there are few or no turns, its basically just one large loop for many many kms - so I was able to see that this was nothing to do with upcoming turns etc - in no case when the portal spawned was there any upcoming turn that I could reach within 2 minutes on the route, so incorrect spawn location seems unrelated to turns.

Hope this information helps when this is eventually picked up by Zwift support (I live in hope, don’t say I’m not an optimist…)

How is your power doing when this happens? The most logical explanation would be that your power drops momentarily to (near) zero when the portal appears right in front of you. If you are using the 3-second smoothing, try turning it off to see the actual watts.

Thanks, no I don’t believe this is anything to do with power, power is consistent across the 2 minute boundary in each case, I’m in ERG mode. I did not have power smoothing on today. It doesn’t happen at 1:50, or 1:45, or 1:40, or 1:35 etc… just at the 2:00/1:59 mark exactly. Its unlikely to the point I would suggest of impossibility that my power is dropping in some hidden way at exatly 2 minutes from interval end and at no other time.

You’ve been on zwift a while haven’t you? are you just noticing these things?

I personally wouldn’t expect (or even want) Zwift to fix every bug reported. They must have thousands of quirks and oddities that have built up over time. If they really had to jump on every one of these like they were critical it’s all they would be doing, and they would make no progress on anything else.

My guess is Zwift has a certain amount of resourcing applied to a bug backlog, where out of the 1000s of issues they have logged they basically already have some conviction on the first set they would work on given time, and the rest are probably in a big pile. They probably have more bugs incoming to their triage team than they fix in a sprint, so they probably have some triage criteria that determines if it’s worth acting on immediately, or putting it in a pile. They have resourcing applied to new features, but when big regressions show up (such as the bike unlock banner bug that just came up) that basically randomizes one of their devs (or more) significantly, basically slowing down whatever they had planned for that sprint/cycle, while that is happening, more bugs are piling up etc.

Any bug fix, no matter how small has the chance to introduce a regression, it’s possible the bike unlock bug was introduced with a fix to the photo crashing bug for instance, who knows. So each fix needs the appropriate amount of testing etc. Which as we know, seems to be difficult for them given all the regressions we’re seeing lately :slight_smile:

So, if a bug has been around for years, I wouldn’t hold your breath for it. They might have made the call that it’s just not worth the risk to fix, they might have decided it’s ok to live with it.

Doesn’t mean it’s not worth reporting, but if you’re constantly bumping 20 issues every day, it would probably be more useful to choose the most impactful one that you really believe Zwift should jump on and focus on that one, otherwise it probably looks more like noise to anyone watching.

I am a paying customer, I actually believe that yes, I do have a right to expect that bugs are fixed.

But the bigger issue is not that they take a long time to be fixed, its that reports of bugs simply go unacknowledged and unticketed. Its a terrible, terrible customer experience and not one I’ve come across with any other company.

I’m not a developer and it sounds like you might be and know more about this than me. But having worked in customer service in the past, for a company that has developers, I do know that its not normal to simply ignore customers reporting problems, which is my experience to date with Zwift sadly.

1 Like

In most cases I’ve seen the bugs a while, but been patient. I don’t expect fixes overnight. I’ve been hoping that surely someone must have reported them already and Zwift would fix them in good time. But after 18 months of seeing some of the same bugs over and over, day after day, I have finally given up waiting and logged them for myself to try and get attention to them. I don’t expect a miracle, I don’t expect overnight fixes. But I do expect irritating bugs to be addressed, within some kind of readonable timescales. Not days, but within years certainly, and that’s just not happening.

The problem seems so ingrained at this point that half the community is simply resigned to things never getting fixed, and the other half have become active apologists for Zwift.

If they have time to add Lederhosen costumes and Dinosaur outfits, they have time to investigate and fix bugs, but are choosing not to do so.

Prioritizing bug fixing creates a virtuous feedback loop reinforcing initial software quality. If there are no consequences to shipping faulty code, then developers are free to “just ship it” when it doesn’t work properly yet. This outcome is very quickly and easily learned by developers, and why wouldn’t it be? My guess is that given the large number of customer reported problems in every release, the poor engineering response is probably partly due to a weak customer service organization that doesn’t have the institutional power to demand better quality. That makes it a CEO problem as well.


I would agree with absolutely everything above. I use dozens of applications, and they’re constantly receiving updates. Zwift is quite literally the only one out of them all that is both constantly beset by new bugs in every single update (no exaggeration) and also the only one in which bugs simply persist for months or years on end (despite being reported) with no apparent attempt made at fixing them.

I don’t know what is going on within Zwift technical teams, but from a customer perspective, something seems very wrong. It is at the very least out of step with any other company that I have had to deal with. And it is giving me a very poor customer experience compared to any other product I use (and pay for).