Pushback Crashes **SOLVED**

[pracines]

My guess is it’s the weekend and they’re not working right now? Hopefully by tomorrow they’ll be back at it, we can hope? It’s a shame because I really only have simulator time on the weekend and really haven’t been able to with this pushback problem. Praying for a fix tomorrow at this point.

I checked the weekend theory long ago - the last response from Umberto was Thursday the 26th.

[mxyeomans]

Note to self!
Never update before a weekend.
Never update unless absolutely necessary.

In all this madness..I will still say thank you as you try to improve your product. Wing walkers next as it happens with every flight. Thanks..
Looking forward to your fix of the push back feature. For now back to Shift+p 1/2

Valued Customer with almost every product you offer.

[PierreFSX]

Same issue here, error when Pushback starts

Pierre

[PC Pilot]

I’m sure it’s the latest update from GSX causing the issue but I’m kind of glad you mentioned FSCrew. I just might go check it out. Thankfully we still have the built in pushback that came with the sim. Not the best but at least it works.

[mjoneill76]

I've learned my lesson as well...ignore updates!!!

[Heronjr]

+1 

Just bought today the GSX2 Level 2.

P3D V4.5 + KMIA Miami default and PMDG B738F Cargo. Tried twice with the same Couatl Restart error just before "ready to pushback!". I used the FSDT Live Update between sessions, which it seems was useless.

I have GSX since its start. But this last months the updates are twice a week and quite long.

Hope there is a cure.

Regards,
Heron Jr

[Dimon]

Same here

ouatl v3.2 (build 4262)
panic log started on Sun Sep 29 20:45:15 2019

problem raised by addon <unknown>
Traceback (most recent call last):
  File ".\common\fsm.py", line 73, in executeDoFuncToCompletion
  File ".\GSX\assistanceServices\pushBack.py", line 489, in do
TypeError: 'float' object has no attribute '__getitem__'
{'Airport': 'PANC', 'Requested assistance services at': 'Gate C 3', 'User Pos': (61.174677778110535, -149.9841972181738, 48.7477 m, 2.40772 m, 81.96159226362627)}

[virtuali]

I noticed that if we do the live update (of course as administrator) the 'DOWNLOADING file C:\Addon Manager\couatl\GSX\assistanceServices\pushBack.pye' keeps trying to update Try it, update and do it again it will say its updating this same file over and over.

This is not normal, and looks like your local Cloudflare node is not serving the updated file, that's why the updater is trying to download it again.

This is very likely what's causing the error, because if a file depends on another, and one of them is not updated, errors will surely appear. Try Live Update again, I forced a refresh of some files that might hopefully result in your local Cloudflare node being updated correctly.

[virtuali]

1) Umberto is visiting Microsoft - this would be good.
2) There is an agreement/arrangement to not fix this too quickly in order to generate more sales of UGCX - this would not be good.

3) It was a weekend, and I haven't noticed this thread because I was away.

And, there must have been some kind of problem with one (or more) of the Cloudflare nodes because, of course, I couldn't replicate it here ( if I run Live Update, I'm not getting the files from the same server as other users, unless you are located close to me), because from your error log, it shows you all had outdated versions of the pushback file.

As I've said in another post, I forced a refresh, which will hopefully get you the latest files.

Unfortunately, the way Cloudflare updates (or fails to update) files is entirely outside our control. Sometimes it happens, we ask Cloudflare support, they almost invariably reply they cannot replicate the problem, and it eventually fixes itself automatically after a day or two, and usually before the Cloudflare support people have a chance to reply. Sometimes the update files are spread in minutes all over the world, sometimes they get stuck for a couple of days but only on some servers, and we don't have any way to find if there's a problem, until users in the affected node reports it or, if I'm "lucky" enough the affected node is the one closes to me, which is not easy, since there are 170 of them around the world.

[JESEVI]

I am not an expert, but there must be some way to ensure that the remote deployment was successful. Some kind of cheksum or similar, so that if it is not correct the update is ignored.

Just a humble idea.

Best regards

[Pit]

I am not an expert, but there must be some way to ensure that the remote deployment was successful. Some kind of cheksum or similar, so that if it is not correct the update is ignored.

Just a humble idea.

Best regards

I agree wit you!!!
Regards, Pit.

[virtuali]

I am not an expert, but there must be some way to ensure that the remote deployment was successful. Some kind of cheksum or similar, so that if it is not correct the update is ignored.

Of course we use checksums, how else the updater could know if your local file hasn't been updated ? Of course the remote deployment was successful, we surely don't upload wrong stuff by mistake.

What went wrong here, is the synchronization between our own server (which surely contained the correct files), and the Cloudflare cache, which is supposed to replicate our server over the Cloudflare network, which as of today counts 194 servers:

https://www.cloudflare.com/network/

This usually works in less than a hour but, sometimes, SOME servers, get stuck with old files for even a couple of days. The only way for us to know this, other than waiting for reports from affected users, would be using a VPN to impersonate an user from a different country, and trying to connect to *each* of the 194 servers, that would be the only possible way to know if everybody really got the correct file.

There's no way we could work without Cloudflare: a single server for all the world would constantly crash each time we release an update, if the bandwidth cost wouldn't bankrupt us in the meantime...

Not that this affects only us in any way. This summer, Cloudflar went down, and took half of the whole internet with it:

https://www.datacenterdynamics.com/news/cloudflare-goes-down-outage-caused-network-performance-issues/

[tikur.anebesa]

The lesson learned here should be NOT to do any kind of release or patch when you know support won't be available right after the release.   Just my 2 cents. 

[Dimon]

Is there any new update regarding current status? Has the pushback been fixed?

[virtuali]

The lesson learned here should be NOT to do any kind of release or patch when you know support won't be available right after the release.   Just my 2 cents. 

The issue is, it would slow down getting updates for everybody, even those NOT affected.

The most common time we finish something and have an update ready, is usually at the end of the week and, purposely delaying any update to the next Monday would prevent all those not affected by getting the latest files for no reason. And, what if we had a critical bugfix ready on a Friday evening, should we postpone the upload to the next Monday ?