Migration generates inconsistencies between projects and project_info

[frafra]

it is an accepted locale, but if the user has set "Italian" as language this is what happens:

• Error: Language it is not supported index.js:168:59 appears in the Javascript console
• API are broken: curl -H 'Accept-language: it' https://osmit-tm3.wmflabs.org/api/v2/projects/ produces {"Error": "Unable to fetch projects"} (no error if the browser Accepted-language: en

[frafra]

I had a look at the logs, here is what I get if I visit /explore:

2020-09-27 08:53:27,348 CRITICAL: BAD DATA: no info for project 24, locale: it, default None [in /usr/src/app/backend/models/postgis/project_info.py:88]
2020-09-27 08:53:27,348 CRITICAL: Project GET - unhandled error: BAD DATA: no info for project 24, locale: it, default None [in /usr/src/app/backend/api/projects/resources.py:657]

This is due to this code: https://github.com/hotosm/tasking-manager/blob/d94ea226e2142da7e2b4b33755ab12ce41797458/backend/models/postgis/project_info.py#L82-L89

I would like to add that the database has been correctly migrated from a 3.x instance.

tasking-manager=# select default_locale from projects where id=24;
 default_locale 
----------------
 en
(1 row)
tasking-manager=# select locale from project_info where project_id=24;
 locale 
--------
 it
(1 row)

Project 24 is the only one which has only one corresponding project_info entry, instead of the usual two (en + it).

I fixed with this command:

tasking-manager=# update projects SET default_locale = 'it' where id = 24;
UPDATE 1

I think the migration mechanism did something wrong when migrating from 3.4.10 to 4.0.12.

[frafra]

It should not be possible to have such inconsistency. I would propose to add a database constraint.