fix: account for un-checked Article 4 values in GIS API

[jessicamcinchak]

Niche edge case spotted by Jenna while testing constraints here (eg not checking general article4 but still selecting article4.caz 🌀): https://opendigitalplanning.slack.com/archives/CQWPPHQ2X/p1733911237161229?thread_ts=1733763841.300959&cid=CQWPPHQ2X

Example request before: https://api.editor.planx.dev/gis/doncaster?geom=MULTIPOLYGON+%28%28%28-1.116085+53.526454%2C+-1.115971+53.52638%2C+-1.115557+53.526611%2C+-1.115625+53.526654%2C+-1.115823+53.526545%2C+-1.115871+53.526576%2C+-1.116085+53.526454%29%29%29&vals=article4.caz%2CbrownfieldSite%2Cdesignated.AONB%2Cdesignated.conservationArea%2CgreenBelt%2Cdesignated.nationalPark%2Cdesignated.nationalPark.broads%2Cdesignated.WHS%2Cflood%2Clisted%2Cmonument%2Cnature.ASNW%2Cnature.ramsarSite%2Cnature.SAC%2Cnature.SPA%2Cnature.SSSI%2CregisteredPark%2Ctpo%2Croad.classified

After: https://api.4066.planx.pizza/gis/doncaster?geom=MULTIPOLYGON+%28%28%28-1.116085+53.526454%2C+-1.115971+53.52638%2C+-1.115557+53.526611%2C+-1.115625+53.526654%2C+-1.115823+53.526545%2C+-1.115871+53.526576%2C+-1.116085+53.526454%29%29%29&vals=article4.caz%2CbrownfieldSite%2Cdesignated.AONB%2Cdesignated.conservationArea%2CgreenBelt%2Cdesignated.nationalPark%2Cdesignated.nationalPark.broads%2Cdesignated.WHS%2Cflood%2Clisted%2Cmonument%2Cnature.ASNW%2Cnature.ramsarSite%2Cnature.SAC%2Cnature.SPA%2Cnature.SSSI%2CregisteredPark%2Ctpo%2Croad.classified

[DafyddLlyr]

This is a good spot by Jenna!

Now that constraints are optional, I think we actually need to also update the type to reflect this on line 148. I'd guess there's a few other places in this file we're working from the assumption that all constraints will be returned?

I think it's just a case of adding Partial<T> here -

  // --- INTERSECTIONS ---
  // check for & add any 'positive' constraints to the formattedResult
  let formattedResult: Partial<Record<string, Constraint>> = {};

[github-actions]

Removed vultr server and associated DNS entries

[jessicamcinchak]

Now that constraints are optional, I think we actually need to also update the type to reflect this on line 148. I'd guess there's a few other places in this file we're working from the assumption that all constraints will be returned?

I think it's just a case of adding Partial<T> here -

  // --- INTERSECTIONS ---
  // check for & add any 'positive' constraints to the formattedResult
  let formattedResult: Partial<Record<string, Constraint>> = {};

Good question @DafyddLlyr - but the constraints response type never checks actual key/property names returned (here nor ODP Schema) because this varies depending on each councils Article 4s (and can be actual 100s of varying keys depending on council)! So this type is still correct as-is based because Constraint here is simply describing the properties expected for each item returned, not actual key/property names -

August and I had really sweated the designated, listed, and flood parent/child cases but missed this article4/article4.caz one.

[DafyddLlyr]

Thanks for example requests - this shows this fixes the problem 👍 Approved and happy to merge so we can keep testing.

I've just checked this out a bit more and I think the Partial<> is most correct - currently the type says all strings are valid keys and will have a corresponding Constraint. I know we're not defining them per-dataset here but adding Partial<> would illustrate that it's not all strings that are valid keys, just some undeclared subset.

The current type allows this -

If we add Partial it would have caught the issue Jenna flagged as a type error -

There are a few more cascading type fixes that fall out from this change though (hopefully just adding more optional chaining) - happy for this to be a fix later / have on the radar issue as opposed to blocking this fix.