Task Manager map slow to redraw

[Adrian-Shobrooke]

Describe the bug
The TM map is very slow to redraw after submitting a task as complete. Project 54291

To Reproduce
Steps to reproduce the behavior:

1. Open a task
2. Map it
3. Submit completed=yes
4. See error

Expected behavior
A rapid redraw to select next task

Screenshots
White screen while waiting for redraw

Desktop (please complete the following information):

• OS: Ubuntu 24.04.4 LTS
• Browser Firefox
• Version 152.0.3 (64 bit)

Additional context
131 mappers online

[linear]

TECH-1226

[Adrian-Shobrooke]

The map is also slow to redraw once a task is selected and editing is taking place in JOSM. I have completed simple tasks in JOSM, uploaded to OSM, the selected the completion tab and the map has not completed updating.

[Patrik-Br]

I agree with Adrian, afaik the issue is on all projects, also smaller ones. It is frustrating for both mappers and validators when they have to wait after submitting every single task.

[Adrian-Shobrooke]

I'd say this problem seems to have got worse. I'm now not getting a map and task grid if I select the project from the Explore Projects page, That used to work up until a few minutes ago. Might be a one off issue, I hope so.

[spwoodcock]

Thanks for flagging all!

As per the responsible AI guide I would say this is a good use case for an LLM to investigate (especially considering I'm probably least familiar with the TM codebase).

I used Opus 4.7, verified the analysis myself in the code, and this is the result:

---

Root cause analysis — #7280

There isn't a single cause; it's a stack of amplifying issues. Below is what happens after a mapper hits Submit completed, and why the map also flickers when task statuses change in the background.

The submit → white-screen sequence

1. submitTaskMutation POSTs the completion, then calls navigate('/projects/:id/tasks/') (actionSidebars.js:103-111). The action page unmounts; TaskSelection (taskSelection/index.js:55) remounts.

2. useTasksQuery (api/projects.js:125) is invoked in TaskSelection with cacheTime: 0, enabled: false (taskSelection/index.js:91-97). The inline comment calls this a "workaround" for stale statuses. Effect: on every remount, no cached GeoJSON is available, and a fresh GET /projects/:id/tasks/ refetch is forced.

3. Until tasksData returns, tasks is undefined (index.js:104). The ReactPlaceholder gate at index.js:356 (ready={typeof tasks === 'object' && mapInit && !isPriorityAreasLoading}) is false → the whole map is replaced by the loading placeholder = the white screen. On project 54291 with hundreds of tasks + 131 concurrent mappers hammering that endpoint, this response is the long tail.

Why the map thrashes even when data is ready

4. updateTasksStatus (utils/updateTasksStatus.js:2) does JSON.parse(JSON.stringify(tasks)) — a full deep clone of the task GeoJSON — and is called on every render of TaskSelection (index.js:104, unmemoized). Every render produces a new tasks object identity.

5. That new reference flows into TasksMap as mapResults, which is a dep of the giant useLayoutEffect at map.js:96-490. The effect re-runs on every parent render.

6. That effect's cleanup (map.js:465-472) unconditionally sets all taskMapLayers and countryMapLayers to visibility: 'none' before the next run, which then toggles them back to 'visible'. Between cleanup and re-run there's a paint window where the task grid is invisible — the flicker/flash. It's also useLayoutEffect, so it blocks paint.

7. Extra: map.on('click', 'tasks-fill', onSelectTaskClick) is registered twice (once in maplibreLayerDefn line 399, once in the refill branch line 446) but the cleanup only offs the second. The in-file comment even flags this: "These will accumulate and need cleanup" (line 445). Each remount piles more listeners onto the previous map (though map is recreated on remount here, so this leaks within a session rather than across).

Amplifiers running in the background

8. useActivitiesQuery (api/projects.js:119) has refetchInterval: 60_000 and refetchOnWindowFocus: true. Every activities response changes the activities reference → updateTasksStatus re-runs → new tasks object → map effect re-runs → hide/show flicker (item 6). Multiply by the number of mappers refreshing status.

9. useProjectContributionsQuery (index.js:86-90) refetches every 60s while on the contributions tab — same cascade.

10. useEffect at index.js:123-127 triggers another refetchTasks() whenever tasksData?.features.length !== activities?.activity.length. With cacheTime: 0, tasksData is briefly undefined on mount, so this can fire an extra full-tasks refetch immediately after the initial one.

The dominant cost

For the acute "white screen after submit" symptom, (2) (forced full refetch with no cache) + (3) (placeholder gate) is the primary cause — a network wait, not a rendering wait. Under load (131 mappers, large project) the /tasks/ endpoint is what's slow.

For the "slow to redraw when status changes" symptom (Adrian's follow-up), (4) + (6) is dominant — deep-cloning the whole grid and hiding all layers on every parent render is unnecessary work whether or not the data actually changed.

The cacheTime: 0 workaround at index.js:95 is worth interrogating — whoever added it did so because task statuses weren't updating when coming from the action page. The correct fix is to invalidate the ['project-tasks', projectId] query on successful submit, not disable caching entirely. That single change would likely eliminate the white screen.

---

My Take

1. If we have some good monitoring, e.g. Sentry or AWS metrics, perhaps we can pinpoint any time periods when the /tasks/ endpoint gets hammered by many mappers, and if there is introduced latency as a result. That would help pinpoint if it's an issue, although the proposal suggested sounds sensible.
2. The suggestion about the deep cloning is an optimisation, but probably not a root cause of the issues here.
3. Keeping the cache enabled would mean users see an old version of the map, rather than a white screen, until it's updated - probably a nicer user experience?