Concurrent changes to the same OSHEntity are not preserved

[SlowMo24]

Describe the bug The following code can be used to retrieve all modifications of a OSHEntity (FULL history):

OSHEntities.getModificationTimestamps(oshentity).stream().parallel()
                                .map(oshdbtimestamp -> {
                                  return OSHEntities.getByTimestamp(oshentity, oshdbtimestamp);
                                })

Concurrent edits (within the same second) to the same OSH-Entity are possible but neglected by the logic choosing only the first edit during one second. This also creates possible missing data in the OSHDB-API ContributionView.

To Reproduce See above, I have no actual OSHEntity for testing available at the moment.

Expected behavior Return ALL intermediate stages.

Additional context It is unclear how common this bug is. A data analysis might be useful to check whether this is worth investigating.

[tyrasd]

Note: Concurrent edits cannot happen in major versions of OSM objects because of the "optimistic locking" mechanism of the OSM API (concurrent uploads will cause a conflict in one of the uploaders). But it is possible that two mappers independently edit different members of the same object (more likely on relations, but in theory it could happen with ways as well), thus creating two minor versions of an OSM object at the same second.

I'm not sure if this actually occurs in practice (if I had to guess, I'd say it happens, but probably very seldomly).

[rtroilo]

Note: Concurrent edits within the same seconds are possible, but very unlikely, the "optimistic locking" prevent concurrent edits (edits of the same version) but does not prevent multiple edits within the same second.

[tyrasd]

Note: Concurrent edits within the same seconds are possible, but very unlikely, the "optimistic locking" prevent concurrent edits (edits of the same version) but does not prevent multiple edits within the same second.

Well, how do you define "concurrent edit"? For me it was when two different people independently edit the same object-version and upload it at the same second. This would always result in a conflict.

Or are you talking about very high frequency sequential uploads (which might also occur when automated scripts are involved, perhaps)?

Or am I overlooking some possible cases?

[rtroilo]

My note where base on the issue description of @SlowMo24

Concurrent edits (within the same second) to the same OSH-Entity are possible but neglected by the logic choosing only the first edit during one second. This also creates possible missing data in the OSHDB-API ContributionView

Which are technically possible, and probably we will find such a case in the full-history dump. But sure, you are right, depends on the definition on "concurrent edits".

[tyrasd]

Ah ok, sure. :sweat_smile: As I wrote above, the most likely situation would be in concurrent creations of minor versions of relation geometries.

It's definitely a bug that those are not reported by the oshdb api. However, since these only occur in very rare situations (and we don't even have any concrete examples from the real world yet), I added the priority:low label. :blush: I hope that's ok for now.

[Hagellach37]

This is a border case. Out of scope of OSHDB.