[PROD] The id for admin2 from vectortile layers does not match.

[tnagorra]

Issue

The id for admin2 from vectortile layers does not match the id for admin2 from the server database.

Steps to reproduce

• Go to 3W Project Form
• Enter Country, Admin1 and Admin 2
• Submit the form.
• The form cannot be submitted.

Expected behaviour

User should be able to save the form.

Impact

This should affect all the users trying to submit 3W Project Form with admin2 information.

Is there a workaround?

There are not workarounds.

[batpad]

cc @geohacker - I think if you, me, @szabozoltan69 and @tnagorra look at this together, you'll be able to guide on the best solution here.

[geohacker]

@szabozoltan69 @tnagorra possible for you to give me one example admin2 so i can verify on the tiles?

[szabozoltan69]

... one example admin2 so i can verify on the tiles?

Here, on staging there are some examples:
https://goadmin-stage.ifrc.org/en/admin/api/admin2/
(Or the similar on prod, without "-stage".)

E.g.
https://goadmin-stage.ifrc.org/en/admin/api/admin2/22
is Syrian Arab Republic - Homs - Ar-Rastan
SY0404
This ID is identical to the Prod's one (and has the same name).

[geohacker]

Thank you @szabozoltan69. So in the tiles we have the following for the Homs - Ar-Rastan example you shared above. The thing that's missing here is the code. Is that what @tnagorra is referring to?

[tnagorra]

@szabozoltan69 The ids on production and stating is the same right now because we are using the clone of production database on the staging as well (for the rewrite)

@geohacker
The id for Syria > Homs > Ar-Rastan is 3792, which is the only unique identifer for that admin2
If you look at the the id for Syria > Homs > Ar-Rastan in the GO backend, the id is 22

Also, there are only 1035 admin2 rows in the Go backend.

The id coming from the vector tiles did match the id from the backend on the ACTUAL staging database.

[szabozoltan69]

The ids on production and staging is the same right now

Yes.
The most of the admin2 work happened on the old (already not used) staging database.

A question: is it good to do changes in develop, or would it be better in web-rewrite? (The failure of snap tests make this question interesting: should we follow both snapshots, in develop with old structures... and at develop<-web-rewrite merge time with conflicts?)

[tnagorra]

@szabozoltan69 This should not be a major change on the frontend so we can either do the change on go-frontend (develop) or go-web-app.

[szabozoltan69]

@tnagorra It's recently a backend change of geohacker, so (at least the backend part) it would be fine to do in web-rewrite to be able to test it on Staging.

[tnagorra]

@szabozoltan69 @geohacker Can you fill me in the details of how the admin1 and admin2 layers are kept in sync with the GO database?

[szabozoltan69]

There is a backend job (see the above change) which sends data from GO database to MapBox and creates layers there. From that data sending an id (code) was missing, that causes the trouble. We have to rerun this repared job to fix the missing "code" id. At first on Staging, then, if works, on Prod.

[tnagorra]

Thanks @szabozoltan69 for the clarification. Please let me know once the fix has been deployed to staging so that I can also confirm the changes.