Add community knowledge file: integration event parameter is a breaking change

[jeffreybulanadi]

Adds integration-event-parameter-is-a-breaking-change to community/knowledge/events/.

Adding a parameter directly to an existing [IntegrationEvent] breaks every subscriber immediately — no deprecation period, no warning, no grace. The correct pattern is to add a new overloaded event alongside the original, mark the original [Obsolete], and raise both during the transition period.

Includes .good.al and .bad.al sibling samples.

[JesperSchulz]

It is not a breaking change? You can add parameters all you like, without breaking existing subscribers. You cannot change existing parameters, neither can you insert new ones in the middle of the parameter list. But you can append. I don't think this article is right.

[JesperSchulz]

The best-practice recommendation is reasonable, but the core premise of this file, that adding a parameter to an existing integration event breaks every subscriber at compile time, isn't correct, and the .bad.al sample demonstrates a compile error that doesn't actually happen.

In AL, a subscriber can declare a left-anchored subset of the publisher's parameters and omit trailing ones. So when .bad.al appends ShipmentNo to the end of the publisher:

procedure OnAfterPostSalesOrder(var SalesHeader: Record "Sales Header"; ShipmentNo: Code[20])

this subscriber still compiles fine — it just ignores the new trailing parameter:

local procedure HandleAfterPostSalesOrder(var SalesHeader: Record "Sales Header")

There's no AL0306 here. Appending a parameter at the end is actually the safe case, so the example contradicts itself.

The real story is more nuanced and worth capturing instead:

• Existing subscribers keep compiling but silently never receive the new argument, so they miss the data — that's the actual risk.
• The genuinely breaking edits are removing a parameter, changing a parameter's name/type, reordering, or inserting a parameter before ones a subscriber already uses — those break the left-anchored name/type match.

I'd keep the "add a new overload and mark the original [Obsolete]" guidance, since that's good advice, but fix the rationale and rework .bad.al. As written, this would teach the agent incorrect compiler behavior.

Refs: Subscribing to events (Example 1 shows subset matching) and the EventSubscriber attribute reference.

[JesperSchulz]

Covered in a different PR.