Task Data is Imported into Multiple Data Layers (or Existing Ones) when Multitask Validating via the HOT Tasking Manager

[martien-vdg]

What steps will reproduce the problem?

1. Select multiple tasks for validation in the HOT Tasking Manager
2. Upload the data and task boundaries to JOSM
3. Check the JOSM layer panel for result

What is the expected result?

All data are in one data layer

What happens instead?

2 things can happen:

• Only part of the data is loaded in data layer, data incomplete
• All data is loaded in 2 seperate layers

Please provide any additional information below. Attach a screenshot if possible.

• Task boundaries are loaded okay
• Issue seems to happen at random, is not always reproducable
• Issue not restricted to specific project or browser
• No issue when using iD Editor
• See for more details this Slack discussion: ​https://hotosm.slack.com/archives/C319P09PB/p1718997016201369
• In attachment of this ticket you find results of jq output of HAR file. Also included are screenshots of JOSM

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2024-07-02 17:10:50 +0200 (Tue, 02 Jul 2024)
Revision:19128
Build-Date:2024-07-03 01:31:15
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (19128 en) Windows 10 64-Bit
OS Build number: Windows 10 Pro 22H2 (19045)
Memory Usage: 540 MB / 4070 MB (294 MB allocated, but free)
Java version: 17.0.11+9, Eclipse Adoptium, OpenJDK 64-Bit Server VM
Look and Feel: com.formdev.flatlaf.FlatDarculaLaf
Screen: \Display0 1920x1080x32bpp@60Hz (scaling 1.25×1.25) \Display1 1920x1200x32bpp@59Hz (scaling 1.25×1.25) \Display2 1920x1080x32bpp@59Hz (scaling 1.25×1.25)
Maximum Screen Size: 1920×1200
Best cursor sizes: 16×16→32×32, 32×32→32×32
System property file.encoding: Cp1252
System property sun.jnu.encoding: Cp1252
Locale info: en_US
Numbers with default locale: 1234567890 -> 1234567890
VM arguments: [-Duser.home=%UserProfile%]

Plugins:
+ Create_grid_of_ways (36178)
+ FastDraw (36226)
+ Mapillary (2.2.4)
+ SimplifyArea (36209)
+ apache-commons (36273)
+ apache-http (36273)
+ buildings_tools (36226)
+ changeset-viewer (0.0.7)
+ continuosDownload (103)
+ flatlaf (36176)
+ gridify (1718663815)
+ jackson (36273)
+ jna (36273)
+ log4j (36273)
+ mapathoner (1.5.5)
+ markseen (14)
+ measurement (36256)
+ reltoolbox (36280)
+ reverter (36256)
+ scripting (v0.3.1)
+ terracer (36205)
+ todo (137)
+ turnrestrictions (36226)
+ undelete (36226)
+ utilsplugin2 (36241)

Tagging presets:
+ C:\Users\Public\Documents\portableappsPlatform\scripts\josm.building.xml

Map paint styles:
+ https://gitlab.com/peculiar-theater/mapcss/-/raw/main/tm-taskgrid/tm-taskgrid.mapcss
+ https://gitlab.com/peculiar-theater/mapcss/-/archive/main/mapcss-main.zip?path=tm-taskgrid
+ https://github.com/MissingMaps/josm_styles/archive/master.zip
+ https://github.com/osmlab/applepaintstyles/archive/main.zip
+ https://josm.openstreetmap.de/josmfile?page=Styles/ColorWays&style
+ https://josm.openstreetmap.de/josmfile?page=Styles/NewModifiedBuildings&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Styles/ModifiedHighways&zip=1
- C:\Users\<user.name>\Desktop\HOT OSM\mapcss\modified-highways\modified-highways.mapcss
- C:\Users\<user.name>\Desktop\HOT OSM\mapcss\new-modified-buildings\test\test-new-modified.mapcss
- https://josm.openstreetmap.de/josmfile?page=Styles/LayerChecker&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Modified&zip=1
- C:\Users\<user.name>\Desktop\HOT OSM\mapcss\user.mapcss
- https://github.com/MissingMaps/josm_styles/archive/master.zip
- https://github.com/osmlab/appledata/archive/josm_paint_inline_validation.zip
- https://github.com/osmlab/appledata/archive/josm_paint_inline_validation.zip
- https://raw.githubusercontent.com/MarkCupitt/HOT-Osm-Validation/44b408bcfb9818e7f6a69eea7022d26299a7ba7a/HOT-Validate.mapcss
- https://github.com/hotosm/HDM-JOSM-style/archive/master.zip

Validator rules:
+ https://josm.openstreetmap.de/josmfile?page=Rules/KeepRight&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Rules/QAToolInspiredValidations&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Rules/ValidatingBuildingsInHOTTMProjects&zip=1

Last errors/warnings:
- 00000.617 W: extended font config - overriding 'filename.Myanmar_Text=mmrtext.ttf' with 'MMRTEXT.TTF'
- 00000.622 W: extended font config - overriding 'filename.Mongolian_Baiti=monbaiti.ttf' with 'MONBAITI.TTF'
- 00004.564 W: Unable to request certificate of https://roottest-g3.pkioverheid.nl
- 00004.881 W: Unable to request certificate of https://roottest-g3.pkioverheid.nl

[martien-vdg]

jq output & screenshots JOSM

[taylor.smock]

Using the following script, I was able to reproduce what I think the issue is.

#!/usr/bin/env bash
path="${HOME}/Downloads/multi-tasks-issue"
OLD_IFS=${IFS}
for r in $(find "${path}" -type f -name 'result.txt'); do
  echo $r
  IFS=$'\n'
  for i in $(cat "${r}" | jq -r '"\(.request.method) \(.request.url)"'); do
    IFS=$OLD_IFS
    curl -X $i
  done
  sleep 10
done

Looking at the console logs from the last call (where I end up having missing download areas), we are getting

2024-07-25 06:24:04.645 INFO: RemoteControl received: GET /load_and_zoom?left=143.905792&bottom=-5.610519&right=143.911285&top=-5.606419&changeset_comment=%23hotosm-project-16937%20%23PNG2024Landslide%20%23OSMPNG%20%23OMGuru%20%23APHub%20mapped%20buildings%20%20%23CCC2024&changeset_source=Bing&new_layer=false&layer_name=OSM%20Data HTTP/1.1
2024-07-25 06:24:04.645 INFO: RemoteControl: no download necessary
2024-07-25 06:24:04.666 INFO: RemoteControl received: GET /load_and_zoom?left=143.911285&bottom=-5.609152&right=143.916779&top=-5.605052&changeset_comment=%23hotosm-project-16937%20%23PNG2024Landslide%20%23OSMPNG%20%23OMGuru%20%23APHub%20mapped%20buildings%20%20%23CCC2024&changeset_source=Bing&new_layer=false&layer_name=OSM%20Data HTTP/1.1
2024-07-25 06:24:04.666 INFO: RemoteControl: no download necessary
2024-07-25 06:24:04.689 INFO: RemoteControl received: GET /load_and_zoom?left=143.911285&bottom=-5.614619&right=143.916779&top=-5.609152&changeset_comment=%23hotosm-project-16937%20%23PNG2024Landslide%20%23OSMPNG%20%23OMGuru%20%23APHub%20mapped%20buildings%20%20%23CCC2024&changeset_source=Bing&new_layer=false&layer_name=OSM%20Data HTTP/1.1
2024-07-25 06:24:04.689 INFO: RemoteControl: no download necessary
2024-07-25 06:24:04.715 INFO: RemoteControl received: GET /load_and_zoom?left=143.920898&bottom=-5.621453&right=143.926392&top=-5.614619&changeset_comment=%23hotosm-project-16937%20%23PNG2024Landslide%20%23OSMPNG%20%23OMGuru%20%23APHub%20mapped%20buildings%20%20%23CCC2024&changeset_source=Bing&new_layer=false&layer_name=OSM%20Data HTTP/1.1
2024-07-25 06:24:04.715 INFO: RemoteControl: no download necessary

@martien-vdg: I have no clue if this is your problem. It looks like you run JOSM from console/script. Can you check and see if you have no download necessary when you encounter the problem with the Tasking Manager?

This only occurred for me on the last loaded file.

[taylor.smock]

OK. After a bit of debugging, I think I know what the problem is.

We have a race condition.

The /load_and_zoom call for JOSM returns effectively immediately, without waiting for the import to finish. This means the following can happen:

1. GET /load_and_zoom?left=143.916779&bottom=-5.614619&right=143.922272&top=-5.607786&changeset_comment=comment&changeset_source=Bing&new_layer=true&layer_name=OSM%20Data2
2. GET /load_and_zoom?left=143.905792&bottom=-5.610519&right=143.911285&top=-5.606419&changeset_comment=comment&changeset_source=Bing&new_layer=false&layer_name=OSM%20Data2
3. The new layer from (1) is created
4. Any additional /load_and_zoom calls are appropriately put in the new layer.

I really don't know what would be better; waiting to return ok until completion if new_layer=true, waiting in remote control server for the expected layer name to show up, or what.

[taylor.smock]

In 19152/josm:

See #23821: Refactor LoadAndZoomHandler and add tests

This fixes some lint issues, specifically in regard to method complexity.

[taylor.smock]

In 19153/josm:

Fix #23821: Ensure that a new layer is loaded prior to loading additional data to that layer

This occurred due to a race condition, whereby the /load_and_zoom call would
return immediately prior to the download finishing for the new layer and the
next /load_and_zoom call merging onto a pre-existing layer.

This could be fixed in one of two different ways:

1. Block the RemoteControl thread
2. Have some method for ensuring that a new layer is loaded first

While we are effectively doing (1), it was easier to do (2) as well for testing
purposes. This means the RemoteControl thread could spin off a thread for each
request to /load_and_zoom and this particular issue should not reappear.

This does not control for cases where a user calls /load_and_zoom like so:

1. new_layer=true + layer_name=first
2. new_layer=true + layer_name=second
3. new_layer=false + layer_name=first
4. new_layer=false + layer_name=second

Both (1) and (2) will complete before (3) and (4) are run. However, both (3) and
(4) will be loaded into the last layer loaded.

[taylor.smock]

@martien-vdg: Thank you for following up with the information I needed to reproduce the problem.

[taylor.smock]

In 19196/josm:

See #23821: Show confirmation dialogs in the order in which the remote control commands were sent to JOSM

[Gregory]

This is an update after a small scale experiment loading tasks for validation ~ 20 times in JOSM 19196. I only used the staging site this time; I'm assuming that it also happens on the HOT TM based on messages in the slack thread regarding this issue.

Reproduction Instructions;

1. Log in to HOT TM, or the Staging Site.
2. Find a project (on which you are permitted to validate) with multiple tasks marked as mapped.
3. Run JOSM and allow it to load.
4. Ensure that manual confirmation of remote control actions is enabled, via JOSM remote preferences.

a) To see the error variation where data is loaded into existing layers you can “open location” (ctrl + l) and input the following, then downloading:

https://tasking-manager-tm4-production-api.hotosm.org/api/v2/projects/13763/tasks/?as_file=true&format=geojson

5. Select multiple tasks to validate, and begin validation; pop-ups should now begin appearing in JOSM asking for your confirmation to import data. (In my experiments I chose to validate 4 tasks simultaneously, and I think that this is a good number to test, but it also occurs with over 100 tasks selected).
6. One by one, accept the requests by clicking the “yes once” button on all of the pop-ups. If the yes always button is used on task data requests, then it will alter the behaviour, and JOSM will have to be reloaded to load task data individually.
7. You may now see that the task data is loaded into multiple OSM Data layers, if no data layers were previously loaded. If at least one data layer was previously loaded then some of the OSM data may be loaded into existing layers. N.B. Although I was able to repeatedly trigger the error very consistently, the error is not guaranteed to occur, and therefore you may need to (optionally delete the existing layers loaded in JOSM, and) reload the editor via the Tasking Manager several times.

Observations;

The error appears to occur less often; I was able to trigger it twice in ~ 20 repetitions.

The pop-ups could be served in various orders. The task with the smallest ID (number) appears to be unique, because it was the first task to load into a newly created layer, and it always loaded into that new layer. It was also the only task to ever be loaded into a separate layer on its own, and not to be loaded into existing layers.

Fig.1. Tasks loading into existing layers on JOSM version 19196 4 tasks with 1 in 1 layer and 3 in the other

Fig.2. Task Data Loading in Multipe Layers on JOSM Version 19196

Fig.3. Task Data Loading into Existing Layers on JOSM Version 19196

Fig.4. Task with Lowest ID Creating a New Layer on JOSM Version 19196

[anonymous]

Images of Error Described in Ticket 23821 Occuring in JOSM 19196

[taylor.smock]

In 19200/josm:

Fix #23821: Ensure that remote control commands are processed in order

This reverts or partially reverts r19153 and r19196 in favour of forcing ordering
in the RequestProcessor#run method. This does not block the server thread, but
it can mean that we have a bunch of processor threads that are waiting on the
previous processor thread.

[Gregory]

Image of the error occuring in JOSM 19202

[Gregory]

I am reopening the ticket as I have found that the error still occurs when using JOSM version 19202 and both the HOT tasking manager production and staging site.

Observations (based on 8 reps with 2 resulting in error): Mostly the same as before (Applies when using both the production and staging site). The popups in JOSM now appear one at a time and the next one does not show until the currently visible one has been resolved, previously the task data popups would all appear without having to take further action. The task data popups are still served in various permutations. The error only occured when the task with the smallest ID number (in the tasking manager) was imported last, and the ID of the task imported before it was not an adjacent natural number. e.g. if the tasks were imported in the order (273,274,275,272).

If they were instead imported in the order (275,274,273,272); the error would not occur.

[Gregory]

The variation of the error where data is loaded into existing layers still occured. It's possible that the behaviour changed after relocking (extending) tasks for more time and then downloading the task grid using ctrl+l before reloading the editor. The tasks all loaded in order from smallest to largest ID for ~ 10 reps in a row.

After stoping validation and validating the same tasks again, some of the task data loaded into the task grid layer on the initial import.

[Gregory]

Some images are marked with the order that task data was imported. (+NL marks the task which created the new layer) (NL marks tasks loaded into that new layer)

[taylor.smock]

@Gregory: Please open a new ticket.

[Gregory]

@taylor.smock: sure, but before I do could you please to tell me why you want me to open a new ticket, so that I can give you what you want when I do, and so that I can use that understanding in any future tickets I open.

I reopened this one, becuase it appears to me like it's the same error, given that the reproduction steps are the same; I didn't want to duplicate tickets. How would I differentiate between the new ticket and this one (in the title and keywords for example), if I think it's the same error?

[anonymous]

Replying to taylor.smock:

@Gregory: Please open a new ticket.

Sure, but before I do could you please to tell me why you want me to open a new ticket, so that I can give you what you want when I do, and so that I can use that understanding in any future tickets I open.

I reopened this one, becuase it appears to me like it's the same error, given that the reproduction steps are the same; I didn't want to duplicate tickets. How would I differentiate between the new ticket and this one (in the title and keywords for example), if I think it's the same error?

[stoecker]

I reopened this one, becuase it appears to me like it's the same error, given that the reproduction steps are the same; I didn't want to duplicate tickets. How would I differentiate between the new ticket and this one (in the title and keywords for example), if I think it's the same error?

You can refer to other tickets, but reopening old fixed tickets simply isn't the way to go.