Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-08-06 17:36:53 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
bcquality/microsoft/knowledge/events/adding-a-parameter-to-an-event-is-not-a-breaking-change.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.5 KiB
Raw Permalink Blame History

bc-version domain keywords technologies countries application-area
all
events
event-parameters
signature
subscriber-binding
backward-compatibility
integration-event
breaking-change
false-positive
al
w1
all

Adding a parameter to an event is not a breaking change

Description

Adding a parameter to an existing event publisher does not break existing subscribers. AL binds a subscriber to a publisher by the event name, and the subscriber's parameter list only has to be a subset of the publisher's, matched by name and type. A subscriber that does not declare the new parameter keeps compiling and keeps binding — it simply ignores the addition. This holds for IntegrationEvent and BusinessEvent publishers, and even more plainly for local events. Appending the new parameter at the end keeps the change a clean, reviewable addition (see add-new-event-parameters-at-the-end). LLM reviewers often misreport the mere presence of a new event parameter as a "breaking event signature change" that breaks subscribers, which is incorrect.

Best Practice

Do not flag the addition of a parameter to an event publisher as a breaking or signature-breaking change, and do not claim it breaks existing subscribers. Genuine, separate concerns are covered by their own rules — a parameter inserted in the middle of the list rather than appended (add-new-event-parameters-at-the-end), or a parameter that carries no meaningful value — and should be raised on those grounds, not framed as a backward-compatibility break.