It would be great to see some of these things available for everyone! You are welcome to help us improve the site at https://github.com/openstreetmap/openstreetmap-website

I don’t know Ruby at all so I would be quite useless in contributing to the current codebase.

Even if you don’t want to learn Ruby (and I don’t think you need to know much ruby to contribute, it’s a pretty straightforward codebase without much complex code) then I’m sure you know there’s plenty of other parts of the site like the html, icons, css etc that you could directly contribute to.

I’ve noticed a few UI changes that you’ve tried out on your own codebase, and it would be great to see these kinds of things included in the main project so that our mappers can benefit from them in production. So if you want to make some PRs then I’d be happy to review them. You know what changes you’ve made so you’re in a good position to contribute them to the upstream project!

I faced issues with reproducing deployment scenario on my local machine due to outdated documentation (and since I am a Ruby-noob, I couldn’t fix it myself).

I personally put a lot of effort into the DX (Developer Experience) so if you find any outdated documentation, please let us know!

Most of our documentation focusses on setting up developer environments (as opposed to production environments) but I’m always happy to fix any of our documentation if it’s outdated. So please do report your issues at https://github.com/openstreetmap/openstreetmap-website or you can proposed changes there too. Thanks in advance!

I just want to jump in here and publicly say thank you for these reports, and for giving us time to fix them. Tom and I spent time during the recent Karlsruhe Hack Weekend to go through your reports and make sure that we had addressed them all, and I’m sorry I didn’t get back to you before your disclosure deadline. It looks like you’ve been watching what we were doing anyway since your report is pretty accurate!

One small correction to your report is about “new user tokens system are still using plain text storage” - this isn’t quite accurate. We removed our UserTokens system in https://github.com/openstreetmap/openstreetmap-website/pull/4535 and moved to using a standard Rails token feature: https://edgeapi.rubyonrails.org/classes/ActiveRecord/TokenFor/ClassMethods.html

This feature doesn’t store the tokens anywhere - plaintext or otherwise. They are signed tokens, so the tokens can be sent to users and verified when they are used, without storing anything in the database or elsewhere on the servers.

I’d be happy to see any more bug reports that you come across, and I also invite you to work with us on the main openstreetmap-project directly on these kind of things.

loading the CS on the website or via the API wouldn’t trigger the closing but only trying to upload data into the CS again?

Hmm, not quite.

Remember that all changesets - open or closed - have a closed_at date, it’s just that initially it’s one hour in the future (you can think of it more like “will_be_closed_at”) and often that time has passed already (so more like “was_closed_at”) and the only difference is whether that timestamp is before or after Time.utc.now. There are no updates to the database when a changeset automatically closes, the “will_be_closed_at” timestamp was already saved in the database, either during changeset open or during the last successful update.

The only ways to close a changeset are to a) wait for the closed_at timestamp to pass or b) update the closed_at timestamp to be Time.now.utc by calling the changeset/close API method - which is just an express version of a) for the impatient!

It’s one of these parts of the API where the mental model of a changeset (two states, open vs closed, and various actions like ‘close’ and ‘automatically close’) and the actual code implementation (a predetermined closed_at time, which can be in the future, and can be updated in certain limited circumstances) are quite different. The mental model is useful for mappers and there’s nothing wrong with it, but when you look at the code / database it’s quite different.

Granted, I don’t know where to find the code exactly, but I guess there’s not much “monitoring” involved. You’ll probably see a process that checks every N seconds, whether there are changesets that match Pieter’s description of points 2 and 3 (either 1 hours since the last upload or 24 hours since creation) and then shuts those changesets down.

It’s much simpler than that - there’s no extra monitoring process involved. Whenever something happens to the changeset (e.g. open, diff upload, individual element update, etc), its closed_at attribute is updated.

https://github.com/openstreetmap/openstreetmap-website/blob/e83f0bd13121ab520c68d3a49a3f0f59a1266cd2/app/models/changeset.rb#L186-L198

Then the next time you try to do something (e.g. another diff upload) the code just checks if the changeset closed_at has already passed - if so, the changeset is closed, if not, the closed_at is updated again, etc. The “close changeset” method just checks if the changeset is still open, and if so, sets the closed_at to right now.

https://github.com/openstreetmap/openstreetmap-website/blob/e83f0bd13121ab520c68d3a49a3f0f59a1266cd2/app/models/changeset.rb#L69-L76

So there’s no moving parts within the codebase, no ‘watch’ process and not even an extra update to the db to close each changeset. It’s a clever design (and not something I was involved with!).

I think the more important bits is the side effects on other systems, for example changeset comments, or 3rd-party analysis tools, that might be waiting for a changeset to close before triggering an alert etc. There’s a case to be explored if 24 hours is too high an upper bound for changesets to be kept open (of course, a changeset also needs activity every 60 minutes for every one of those 24 hours, since the changeset closed_at is only extended 60 minutes at a time - so the default is to keep it open for 1 hour (reasonable?) with an upper limit of 24 hours (debatable?)).

there are additional connectivity checks to my other server in Poland. I exclude any downtime that is also present on that server. :-)

Great!

By the way, do you by chance know anything about the official uptime OSM configuration?

No, sorry I don’t. I’m only involved in the software development, not in the production operations.

the checks are executed from a single server in the Hetzner datacenter in Germany

Then you are equally likely to be measuring the network availability of Hetzner.

Fantastic!