Grasp
Public
Showcaseexample/platform-infra #339Markdown

Split the growth_opportunities catalog into dev and prod

Two environments were competing for one Unity Catalog name, so prod apply has failed since v0.67.0. This gives each environment its own catalog and stops the portal API silently reading dev.

OPEN · PLAN FAILINGGrasp · Jul 30, 2026

Three explanations of the same brief

No jargon, about fifteen seconds

Split the growth_opportunities catalog into dev and prod

Someone changed how a program works. Two environments were competing for one Unity Catalog name, so prod apply has failed since v0.67.0. The part to watch: Dev tables live in the old shared catalog.

dev deployprod deploy
The first two parts of the brief's own diagram

34 words · derived from the brief below, no model involved

One catalog name was shared by two environments, and the metastore only allows one owner.

Unity Catalog names are unique per metastore. Both dev and prod declared growth_opportunities, dev won the race, and every prod apply since has failed on a name that already exists.

The fix introduces a catalog_name variable per environment. Dev resolves to growth_opportunities_dev and prod keeps the clean name, which avoids renaming the catalog production already reads from.

The second half of the change is unrelated to Terraform. The portal API resolved its catalog with a null-coalescing fallback, so an unset variable in prod quietly returned dev data instead of failing. That fallback is now a throw.

BEFOREwinsfailsdev deployterragrunt applyprod deployterragrunt applygrowth_opportunitiesunique per metastoreAFTERdev/terragrunt.hclcatalog_name = …_devprod/terragrunt.hclcatalog_name = cleangrowth_opportunities_devgrowth_opportunitiesprevent_destroy
One name owned by two environments, and the same topology after the splitDownload for draw.io

What this brief could not check

  • This brief was written by hand as a design fixture. It is modelled on real work, but no model read a diff to produce it, and its claims should not be relied on.
  • The plan failure is described from its error message. The full CI log was not read, so the message may not be the only failure.
  • Whether the shared catalog holds production data was not determined. That question is unresolved and is the reason the merge order starts where it does.