Crash in MapDataWithEditsSource when a way in a bbox update has missing nodes

[mcliquid]

(I'm posting this here because the file hasn't been modified in SCEE.)
SCEE crashes with a NullPointerException in MapDataWithEditsSource.modifyBBoxMapData(...) when processing map data updates. The crash happens at the point where the code assumes that all nodes of a way are available and uses getWayNodes(way)!!.

From the logcat, the app logs:

Process: de.westnordost.streetcomplete.expert.debug, PID: 12152
java.lang.NullPointerException
at de.westnordost.streetcomplete.data.osm.edits.MapDataWithEditsSource.modifyBBoxMapData(MapDataWithEditsSource.kt:442)
at de.westnordost.streetcomplete.data.osm.edits.MapDataWithEditsSource.getMapDataWithGeometry(MapDataWithEditsSource.kt:273)
at de.westnordost.streetcomplete.screens.main.map.StyleableOverlayManager$setStyledElements$mapData$1$1.invokeSuspend(StyleableOverlayManager.kt:246)
at 
...

and then later crashes in the same code path. This suggests that a way can end up in the bbox-update handling with incomplete node data. The issue may be triggered by an edit state that can happen in SCEE but not in normal StreetComplete, so this may be a compatibility issue between the two codebases rather than a general StreetComplete workflow.

How to Reproduce

1. Open the app with local edits present.
2. Trigger a map data refresh / bbox update.
3. In my case, the app reaches MapDataWithEditsSource.modifyBBoxMapData(...).
4. A way is processed whose nodes are not all available.
5. The app crashes with a NullPointerException.

Expected Behavior

The app should not crash if a way in the bbox update does not have all nodes available. It should handle the incomplete way gracefully, for example by skipping it, logging the problem, or rebuilding the affected map data state safely.

Possible solution / workaround
The issue could be fixed by removing the unsafe !! and handling incomplete ways gracefully, e.g. by skipping ways whose nodes are not fully available. Alternatively, ensure upstream that modifyBBoxMapData is only called with consistent map data where all referenced nodes are present. A defensive check with fallback behavior (skip or remove the way) would prevent crashes without breaking the flow.

This local workaround worked to get the app running again without loosing data:

for (way in addWays) {
            val nodes = getWayNodes(way)
            if (nodes == null) {
                Log.w(TAG, "Skipping way ${way.id} because not all nodes are available")
                continue
            }
            val geometries = nodes.map { ElementGeometryEntry(it.type, it.id, ElementPointGeometry(it.position)) }
            mapData.putAll(nodes, geometries)
        }

Versions affected

• SCEE: v63.0
• Android: 16

[matkoniecz]

Have you tried to reproduce it in SC? Even if this specific file is unmodified in SCEE other modifications (or lack of porting modifications) may be reason for a bug.

[mcliquid]

If I remember correctly, I made changes to a highway in SCEE without uploading them. Then I edited the way in JOSM, splitted the way and uploaded the changes. After that, I opened SCEE again, and the app kept crashing every time I launched it.

I can try again with SC.

[mcliquid]

It's not easy, but it happens with StreetComplete too. You download only part of a very long road into StreetComplete. Then you complete a few tasks without uploading the changes. In the meantime, the road is split up in JOSM and uploaded. Then you upload the changes to StreetComplete: crash and the same log as above.

[Helium314]

The app should not crash if a way in the bbox update does not have all nodes available. It should handle the incomplete way gracefully, for example by skipping it, logging the problem, or rebuilding the affected map data state safely.

see #6419 (comment)

[westnordost]

Hm, true, the assumption is that the data returned by a bbox query on the OSM API contains all the nodes used by all the ways. But what I didn't take into account when making this comment was the updating of elements on a conflict: Here, we only update certain elements (e.g. the way which has new nodes now) without making sure we also update all the nodes referenced by the way.

Must the solution be to on updating an element due to conflict, we also need to update all elements referred by it? (I.e. for ways, also update all its nodes, for relations... I guess... only it's direct children...? Would need to look how the OSM API bbox query behaves for relations...)

Or, can we make the parts of the app robust against this kind of missing data?