@Paddle2See* asked for me to put this in a separate topic so don't go saying it is in the wrong place.

My browser / operating system: Windows NT 10.0, Microsoft Internet Explorer 11.0, Flash 24.0 (release 0)
THIS HAS HAPPENED ON OLDER BROWSERS AND OPERATING SYSTEMS THOUGH!

Topic subject

Since the cloud data stopped working, the cloud data that I have used in this project and this project has not been working properly! (the first one is a special edition of the second one)

Clear explanation of problem

When a tank gets blown up, the Scrapyard of all tanks that have been blown up since I implemented the cloud data into the projects should change by 1. However, instead of doing that, it goes up by 1, then 1/2 a second later, goes back down to what it was before! When I originally implemented the cloud data and the scripting for it, I followed the Scratch Wiki, then checked to see if it was working by running the same project on two different computers at the same time. It worked fine, and up until the cloud data problems started for everyone, it worked without fail. Now, it won't work!

Best way to see the glitch that I am talking about

Use the green tank to blow up another tank. I want you to use the green tank because it's the one that usually covers the Scrapyard variable on startup, so moving that one away from the Scrapyard will let you see the bug.
Or, as requested by @Paddle2See*, use https://scratch.mit.edu/projects/141185537/, although I haven't opened up this project to everyone yet.
What I would like to happen

FIX THE PROBLEM WITH CLOUD DATA PLEASE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

P.S. The Cloud Data in these projects was implemented long before cloud data problems started occurring.
P.P.S. @Paddle2See* asked for me to put this in a separate topic so don't go saying it is in the wrong place.

If a cloud variable keeps changing back to its original value after a project changes it then it means the project has become disconnected from cloud, such that the cloud server will no longer accept its changes. (But the project continues to ask the cloud server for the latest values of cloudvars, which is why they keep resetting back to the current values in the cloud after the project changes them,)

This can happen if the project has not contacted the cloud for some time – the connection ‘times out’ – and that can easily happen if you've been editing a project for some time, without actually running it (so it hasn't changed anything in a while). Or if you stop using a project for a while, or put your laptop to sleep for a while, etc., then the project will be disconnected next time you come back to it.

Also, if you open the project elsewhere (e.g. a different tab or browser), but as the same user, then only the most recently loaded one will be truly connected to cloud. (Any others will only be able to read the cloud values, and any attempt to change cloud values will revert after a second or so.)

The way to fix it is simply to reload the project page.


I'll also note this behaviour is different with the cloud currently only working in fallback polling mode (compared to the previous fast port 531 connection).

In the fast 531 connection case, the project would not continuously poll the server for the latest cloud value, relying instead on the cloud server sending it any changes that happen. If the project became disconnected from cloud, it would never be able to tell for sure, since its own changes would ‘stick’ (it would never know they didn't get through).

In that respect, fallback actually has an advantage over the fast port 531 connection, since it means you can do something like the following to test that the project's cloud change has succeeded:

define set and check cloud data (data)
if <(☁ CloudVar)=(data)> then
stop [this script v] // not much point doing any more...
end
set [curData v] to (☁ CloudVar) // want to check if it reverts back to current value
set [☁ CloudVar v] to (data) // try to change it
repeat (9)
wait (0.2) secs // total of ~1.8 seconds
if <not<(☁ CloudVar)=(data)>> then // check if it got changed back to something else
  if <(☁ CloudVar)=(curData)> then // check if the cloudvar's value reverted back
    say [Failed to save data to cloud... :(]
  else
    say [Someone else overwrote your value...]
  end
  stop [this script v]
end
end
say [Success!] // was still the same after 1.8s, so assume it worked

And, yes, fallback polling is very slow, so you do need to wait >1.5s to be sure the new value has really ‘stuck’ in the cloud.

TBH, even above isn't good enough!
It's possible for the project to send its change of the variable to the cloud server, but end up taking longer to reach it than it takes for the next poll to happen. In that case, what can happen is that the cloudvar reverts back to the old value for one poll, before then going back *again* to the new value you've just set it to on the next poll.

Doesn't happen that often, but… yeah…

TheLogFather wrote:

Snip

So, in summary?

ZZ9PluralZAlpha wrote:

TheLogFather wrote:

Snip

So, in summary?

If it starts happening, reload the project. (And be sure not to have it open in two places at once as the same user.)

–But also see the script above to allow detection of the problem while running the project itself.

TheLogFather wrote:

ZZ9PluralZAlpha wrote:

TheLogFather wrote:

Snip

So, in summary?

If it starts happening, reload the project. (And be sure not to have it open in two places at once as the same user.)

–But also see the script above to allow detection of the problem while running the project itself.

That's quite a hard script. Considering it just did the same thing in a brand new project, I'm pretty sure it's not the project that's the issue.

ZZ9PluralZAlpha wrote:

That's quite a hard script.

Yes.

Welcome to cloud.

ZZ9PluralZAlpha wrote:

Considering it just did the same thing in a brand new project, I'm pretty sure it's not the project that's the issue.

Can you give a project ID, and a brief overview of the changes you expect the project to have made to a cloudvar, and I'll take a look at the cloud log.

TheLogFather wrote:

ZZ9PluralZAlpha wrote:

That's quite a hard script.

Yes.

Welcome to cloud.

ZZ9PluralZAlpha wrote:

Considering it just did the same thing in a brand new project, I'm pretty sure it's not the project that's the issue.

Can you give a project ID, and a brief overview of the changes you expect the project to have made to a cloudvar, and I'll take a look at the cloud log.

I put the link in the OP under the heading of Best way to see the glitch that I am talking about. All the project wants to do with the cloud var is increase its value by 1, but instead, it does that, then goes back down aout 1/2 a second later.

For reference, there's definitely something a bit odd about ZZ9PluralZAlpha's interaction with cloudvars…

See discussion in https://scratch.mit.edu/projects/141195887/#comments-70793981

Also note the entries in the cloud log: https://scratch.mit.edu/cloudmonitor/141195887/
(Go down to where there are attempts to change the cloudvar to 17.)

Looks to be working fine for everyone else…

Actually, @ZZ9PluralZAlpha, I've had a thought…

I wonder if your browser(s), or some ‘net proxy you’re using, is caching the results of the request to the cloud varserver?

If so, that would mean every time the project asks the cloud server for the latest values, it never gets through to the real cloud server, but the cache just returns whatever response it has in its store – which still contains the old cloudvar values (from whenever the cache last updated).

Your update of the cloudvar is really making it to the cloud server (as can be seen from the cloud log), but whenever the project tries to poll for the values, it just keeps getting the old ones.

Do you know if you have a proxy of some kind on your 'net connection? Is there possibly some cache setting on your browser to force it to clear its cache and so get new values?

Thinking about this some more… if it really is a caching issue (as I described above), then it's potentially devastating to a cloud-enabled project whenever you go to it.

I don't know how long the cached data may remain valid (half an hour? an hour? a few hours? a day…?) – i.e. how long before the cache decides that it needs to store a more recent state – but if you revisit a project some time later, then all you see will be the very old data from the last time you visited.

However, all the changes that you make as you run a cloud project do get through to the cloud. That means if your cached data is old, and you do make changes to the cloud data while running the project, then it'll regress it very badly (back to the state when you previously visited the project).

This could be devastating for a voting project which stores whoever voted, for example – when you go to the project a second time, then, it'll revert back, for you, to the state just before you last voted. And then if you try to vote again, it'll revert back for everyone!

That's also the case for my Eclipse 2017 project, for example. If you go to that twice, within the time that the cached data is still invalid, and place your pin position again, it'll lose everyone who's placed a pin since you last tried to place your pin…

Ouch!

Can you go to my test project again and see what number it shows you? Last time you tried to increase the cloudvar, it was on 16 (and you increased it to 17, though you never saw that change ‘stick’).

Does it still say 16? It's currently on 79…

If you do see 79(ish) then can you let me know, and I'll increase it a bit at some point. Then you can go back to it, and see if it still says 79(ish).

TheLogFather wrote:

Thinking about this some more… if it really is a caching issue (as I described above), then it's potentially devastating to a cloud-enabled project whenever you go to it.

I don't know how long the cached data may remain valid (half an hour? an hour? a few hours? a day…?), but if you revisit a project some time later, then all you see will be the very old data from the last time you visited. But all your changes do get through to cloud, so if you attempt to make any changes to that data, it'll regress it very badly.

This could be devastating for a voting project which stores whoever voted, for example – when you go to the project a second time, it'll revert back to the state just before you voted for you. And then if you try to vote again, it'll revert back for everyone!

That's also the case for my Eclipse 2017 project, for example. If you go to that twice, within the time that the cached data is still invalid, and place your pin position again, it'll lose everyone's position since you last tried to place your position…

Ouch!

Can you go to my test project again and see what number it shows you? Last time you tried to increase the cloudvar, it was on 16 (and you increased it to 17, though you never saw that change ‘stick’).

Does it still say 16? It's currently on 79…

If you do see 79(ish) then can you let me know, and I'll increase it a bit at some point. Then you can go back to it, and see if it still says 79(ish).

OK, I'll check it just now.

The test project seems to be giving me (and others) problems today. It updated successfully a few times and failed once. On a previous run, despite saying that it connected properly, nothing was changed and there were no entries at all in the cloud monitor.

Paddle2See wrote:

The test project seems to be giving me (and others) problems today. It updated successfully a few times and failed once. On a previous run, despite saying that it connected properly, nothing was changed and there were no entries at all in the cloud monitor.

Did you reload the project on the first attempt since the last time you tried yesterday? If not, the project's connection to cloud will likely time out, which means that the cloud server will no longer accept any changes from it (though it would continue to poll the cloud for the latest cloud values, so you would see the most up-to-date value, but any time you increased the value it would very quickly change back).

It's fairly common for Scratchers to come across this problem, particularly when editing a project for a while. Since they are not running the project, it makes no changes to cloudvars for a while and so their cloud session times out. And then when they do run it, the project appears to no longer work correctly with cloud…

Also, yes, I see another TWO users, @Scratcher959 and @avarshney, have the same issue as ZZ9 and @andallfor (who also tried again, and failed again).

Apart from that, the log all looks pretty much as I'd expect. (Just the occasional double-entry, where the timing of the fallback polling has meant the user got the old value right after increasing it, which the project noticed and then increased it again – that's precisely the issue that the project is designed to work around.)

Just to keep this topic up-to-date on developments…

It looks like the problem here is likely down to aggressive caching done by IE (and Edge).

Everything works fine for ZZ9PluralZAlpha (and others) when using Chrome or Firefox.

Everyone I've seen so far with the issue, who has also confirmed browser, has said IE or Edge. (And one other of those also confirmed that switching to Chrome fixed it.)

I left some links on the subject of the aggressive caching in IE/Edge in this github issue comment:
https://github.com/LLK/scratch-flash/issues/1267#issuecomment-274571044

TheLogFather wrote:

Just to keep this topic up-to-date on developments…

It looks like the problem here is likely down to aggressive caching done by IE (and Edge).

Everything works fine for ZZ9PluralZAlpha (and others) when using Chrome or Firefox.

Everyone I've seen so far with the issue, who has also confirmed browser, has said IE or Edge. (And one other of those also confirmed that switching to Chrome fixed it.)

I left some links on the subject of the aggressive caching in IE/Edge in this github issue comment:
https://github.com/LLK/scratch-flash/issues/1267#issuecomment-274571044

Cool! Thanks for updating the topic! I've been quite busy working on an elevator project so I'll do the running of the cloud project on Chrome tomorrow. Or maybe when I get into school (because I usually get in a bit early).