Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-08-06 09:26:52 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
bcquality/microsoft/knowledge/breaking-changes/relocating-a-field-to-a-tableextension-is-not-a-deletion.md
wenjiefan 6d1fada5a4 Add FP guards for field relocation to tableextension and event parameter addition 
Two knowledge false-positive guards addressing bug 642303 (agent FPs on BCApps PR #9607):

- breaking-changes: relocating a field to a tableextension in the same app under the same field ID/name is a relocation, not a deletion/rename; the field still resolves on the table, so it must not be flagged as a deleted shipped field or require ObsoleteState staging. Scoped to the contract axis; silent on data migration.

- events: adding a parameter to an event publisher does not break existing subscribers (subscribers bind by name and match a subset), so the addition itself must not be reported as a breaking signature change.
2026-08-04 10:41:03 +02:00

1.8 KiB
Raw Blame History

bc-version domain keywords technologies countries application-area
all
breaking-changes
table-field
tableextension
relocation
field-id
obsoletestate
breaking-change
false-positive
al
w1
all

Relocating a field to a tableextension in the same app is not a deletion

Description

Moving a field out of a base-table definition (or a base-app layer modification of one) into a tableextension that extends the same table, within the same app and keeping the same field ID and name, is a relocation — not a deletion or a rename. After the move the field still exists on the table: Rec."Field Name" and the field ID resolve exactly as before, so dependent extensions that reference the field continue to compile. Nothing in the field's public contract is removed or renamed, so the deprecation lifecycle that protects a genuinely removed field does not apply. LLM reviewers frequently misread the two-sided diff — the field disappearing from the base object and reappearing in the tableextension — as a shipped field being deleted and illegally re-added under the same ID, and demand ObsoleteState = Pending staging that this refactor does not need.

Best Practice

Recognize a field that is removed from a base table (or base-app layer) and re-declared in a tableextension of the same table, with the same field ID and name, as a same-app relocation. Do not flag it as a deleted or renamed shipped field, and do not require ObsoleteState = Pending, ObsoleteReason, ObsoleteTag, or a deprecation window for the move itself. The obsolete-table-fields-instead-of-deleting-them and obsolete-pending-to-removed-staging rules apply to fields that leave the table's contract entirely, not to fields relocated within the same app under an unchanged ID.