fix(service): preserve tag recognizer config on ingestion PUT - #31205
Conversation
Metadata ingestion upserts source tags with a bare CreateTag carrying only classification, name and description. CreateTag defaults recognizers to an empty list and autoClassificationEnabled to false, so the updater could not tell a caller that never heard of these fields from one deliberately clearing them, and every ingestion run stripped the tag's recognizers and switched auto-classification off. PII.Sensitive ships 39 recognizers and is reachable this way through the system-tag name match in tag_utils. Treat the recognizer configuration as one unit that a PUT only touches when it names recognizers. Clearing via PATCH is unaffected, which is the path the UI uses. This mirrors the classification-level guard added in #29668.
❌ PR checklist incompleteThis PR cannot be merged until the following are addressed on its linked issue:
The fields live on the linked issue in the Shipping project (open the issue → right sidebar → Projects). After you set them, re-run this check (or push a commit) — issue/project changes do not re-trigger it automatically. Maintainers can bypass this check by adding the |
✅ Playwright Results — workflow succeededValidated commit ✅ 550 passed · ❌ 0 failed · 🟡 0 flaky · ⏭️ 0 skipped · 🧰 0 lifecycle flaky PerformanceBlocking targets: ✅ met · Optimization targets: 🟡 in progress Shard-job maxima below are not the full workflow wall time; the linked run includes build, fixture, planning, and reporting. 🕒 Full workflow signal wall (to summary) 50m 30s ⏱️ Max setup 3m 3s · max shard execution 17m 22s · max shard-job elapsed before upload 20m 34s · reporting 3s 🌐 199.90 requests/attempt · 2.83 app boots/UI scenario · 2.02% common-shard skew Optimization targets still in progress:
How to debug locally# Download playwright-test-results-<shard> artifact and unzip
npx playwright show-trace path/to/trace.zip # view trace |
Code Review ✅ ApprovedPreserves tag recognizer configuration and auto-classification settings on ingestion PUT operations by anchoring them to whether recognizers are explicitly provided. No issues found. OptionsDisplay: compact → Showing less information. Comment with these commands to change the behavior for this request:
Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source |
#31304) Metadata ingestion upserts source tags with a bare CreateTag carrying only classification, name and description. CreateTag defaults recognizers to an empty list and autoClassificationEnabled to false, so the updater could not tell a caller that never heard of these fields from one deliberately clearing them, and every ingestion run stripped the tag's recognizers and switched auto-classification off. PII.Sensitive ships 39 recognizers and is reachable this way through the system-tag name match in tag_utils. Treat the recognizer configuration as one unit that a PUT only touches when it names recognizers. Clearing via PATCH is unaffected, which is the path the UI uses. This mirrors the classification-level guard added in #29668. (cherry picked from commit fd94194)
#31305) Metadata ingestion upserts source tags with a bare CreateTag carrying only classification, name and description. CreateTag defaults recognizers to an empty list and autoClassificationEnabled to false, so the updater could not tell a caller that never heard of these fields from one deliberately clearing them, and every ingestion run stripped the tag's recognizers and switched auto-classification off. PII.Sensitive ships 39 recognizers and is reachable this way through the system-tag name match in tag_utils. Treat the recognizer configuration as one unit that a PUT only touches when it names recognizers. Clearing via PATCH is unaffected, which is the path the UI uses. This mirrors the classification-level guard added in #29668. (cherry picked from commit fd94194)
Describe your changes:
Fixes #
Metadata ingestion upserts source tags with a bare
CreateTagcarrying only classification, name and description.CreateTagdefaultsrecognizersto an empty list andautoClassificationEnabledtofalse, soTagUpdatercould not tell a caller that never heard of those fields from one deliberately clearing them — every ingestion run stripped the tag's recognizers and switched auto-classification off.PII.Sensitiveships 39 recognizers and is reachable this way:tag_utilswithsystem_tags=True(unitycatalog, databricks, bigquery) matches source tag names against system tags case-insensitively, so a sourcePII/sensitivepair upserts straight over it.This is the tag-level twin of the classification-level bug fixed in #29668; that guard covered
autoClassificationConfigonClassification, but nothing protected the equivalent fields onTag.Fix: treat the recognizer configuration as one unit that a PUT only touches when it names recognizers.
Independent null-guards would not work:
autoClassificationEnabledhas a schema default offalse, so "disable this" and "I never heard of this field" are identical on the wire. Anchoring all three fields to whetherrecognizerswas named gives the server a signal it can actually read. The check isnullOrEmptyrather than== nullbecause nulls are dropped on store and read back as an empty list.A PUT that does name recognizers still replaces them, and clearing via PATCH is unaffected — that is the path the UI uses.
Type of change: