iD: dummy version bump

[tyrasd]

for openstreetmap/iD#10418 (comment)

[tomhughes]

How is this supposed to help? Can somebody explain to me what actual problem is and why this will fix it because this looks suspiciously cargo culty to me...

Reading the iD ticket you seem to think the imagery.json asset is wrong, but if that is so shouldn't we try and find out how that has happened?

[tomhughes]

The production servers all seem to have /imagery.min-cd263495de30d2db72076219027524ea05f895454f7ad0f5279fe382ba396b96.json with a length of 4436859 bytes (which @Firefishy seems to say is the correct length) and an sha256 of 0d39fde1b45e3255171c8519481540de949e386eda0bab29d772239bb8d21a6b both of which also match my own machine.

[tyrasd]

Reading the iD ticket you seem to think the imagery.json asset is wrong

Well, all I can say is that the issue is not limited to the imagery.json asset, see https://community.openstreetmap.org/t/is-the-osm-in-browser-editor-working-currently/117699/4 where the same problem happened to the id.js asset.

shouldn't we try and find out how that has happened?

Yes, any help would be greatly appreciated. From all I can see, this must be caused by something outside of iD itself, so I'm of little help, unfortunately.

The production servers all seem to have […] the correct length

Yeah, that's what I saw as well. So the problem must be somewhere between the rails code and the end users??

[tomhughes]

Well it sounds like some sort of network/client issue, so outside our control if the version of the asset we are serving is correct.

Even if we merged this would it help? Does that version number even get baked into the all the affected files?

[Firefishy]

My thought was maybe some cloudflare edge had a corrupt copy. I purged the cache a day ago.

Clients would continue to cache the bad copy.

Dummy deploy might force a filename has change.

[tomhughes]

The filename will only change if that version number is part of the contents - the hex in the name is just a hash of the contents.

[tyrasd]

The version number is part of the id.js asset, so it would at least trigger a hash change for that particular file. As said in openstreetmap/iD#10418 (comment), I can also produce a "proper" minor release wich would also include an updated imagery.js file, which is the second asset that we've seen this bug occur with. Let me know if I should prepare that.

[tyrasd]

we didn't get any more reports over the weekend. So it seems that the problem has hopefully resolved itself. Let's close this and continue monitoring the situation.