Every attribute label says Unknown
Nearly two thousand attributes had the literal admin label "Unknown". The real labels existed the whole time, one table over, and fixing it in the database would have lasted until the next import.
The admin attribute grid was full of a product named Unknown. Not blank, not the attribute code. The literal string. On production, 1,943 rows had frontend_label = 'Unknown', and some of them were being rendered to the storefront.
Where the real labels were
They were never missing. They were in eav_attribute_label, the store-scoped label table, correctly filled in for every store view. Only the default admin label was wrong.
The cause is a locale mismatch in the PIM connector. When it imports an attribute it looks for a label in the *admin* locale, and writes a translated "Unknown" when it does not find one. The admin locale at default scope was English. The PIM only carried Dutch labels. So every single attribute got the fallback, every single time.
The fix is one method name
Anything rendering an attribute label to a customer should call getStoreLabel(), not getFrontendLabel(). It resolves the store-scoped label and falls back to frontend_label on its own, so it is strictly better in every case. One resolver in the codebase did this correctly and had never had a complaint. Another did not, and that was the bug report.
The tempting fix that does not last
The obvious move is an UPDATE. Copy the Dutch labels over the "Unknown" values and the admin grid is readable again by lunchtime.
It will survive until the next attribute import, which rewrites frontend_label from the PIM and puts every "Unknown" straight back. Anybody looking at it a month later sees a bug that was supposedly fixed and is somehow back, with a commit history that says nothing useful.
The durable options are a code fix, which is small, or filling in the English labels in the PIM, which is tedious but removes the cause. A database fix is neither.
The general version
When a connector owns a column, you do not own that column. Any repair you apply to it is a countdown, not a fix. The question to ask before writing the UPDATE is simply: what writes this value, and when does it next run?