#Issues8 discussing

Hi everyone! 

I'm trying to change the order of the related list in the item "Opportunities" but when I open

Preventing Recursive Lightning Message Service Calls in Screen Flow LWCs Using a Source Flag 

When working with Lightning Message Service (LMS) inside Screen Flow embedded LWCs, communication between components becomes extremely powerful — but it can also introduce unexpected recursive behaviour.

Recently, I encountered an interesting real-world scenario where two LWCs on a Screen Flow were unintentionally triggering each other repeatedly, causing incorrect value population even though the logic looked perfectly fine.

This blog walks through:

•  The Scenario 
•  The Problem 
•  Debugging Process 
•  Root Cause 
•  The Solution (Using Source Flag) 
•  Best Practices 
•  Final Takeaways 

Scenario

I had a Screen Flow containing two Lightning Web Components:

• LWC A — Publishes some values 
• LWC B — Publishes some values 
•  Both components subscribe to the same Lightning Message Channel

So essentially:

•  LWC A publishes → LWC B receives 
•  LWC B publishes → LWC A receives 

This setup is valid and expected — and initially, everything worked correctly.

However, as the use case evolved, values started getting populated incorrectly

. 

Even though:

•  Logic was correct 
•  Variables were correct 
•  Message structure was correct 

The values were getting overwritten incorrectly.

Example Behavior:

1.  LWC A publishes value 
2.  LWC B receives and updates 
3.  LWC B publishes updated value 
4.  LWC A receives again 
5.  LWC A publishes again 
6.  Loop continues... 

This created a recursive publish-subscribe loop

. 

To identify the issue:

•  Added console logs 
•  Checked publish events 
•  Checked subscription callbacks 

While debugging, I noticed:

• Publish method firing multiple times
• Subscription handler triggering repeatedly
• Unexpected value overwrites

This clearly indicated recursive message passing

. 

The root cause was:

Since both components:

•  Subscribe 
•  Update values 
•  Publish again 

It resulted in infinite cross-communication.

This is a common pitfall when using Lightning Message Service with multiple publishers

. 

The Solution — Using a Source Flag

To stop recursion, I introduced a Source Flag inside the message payload.

The idea:

•  Each LWC sends its name as source
•  When receiving a message: 
  •  If message source == current LWC 
  •  Ignore the message 

This prevents recursive triggering.

Example Message Payload

{
    value: selectedValue,
    source: 'LWC_A'
}

Implementation Example

Publisher

publishMessage() {
    const message = {
        value: this.selectedValue,
        source: 'LWC_A'
    };
    publish(this.messageContext, SAMPLEMC, message);
}

Subscriber

subscribeMessage() {
    this.subscription = subscribe(
        this.messageContext,
        SAMPLEMC,
        (message) => {
            if(message.source === 'LWC_A') {
                return;
            }
            this.selectedValue = message.value;
        }
    );
}

1.  LWC A publishes (source = LWC A) 
2.  LWC B receives 
3.  LWC B updates UI 
4.  LWC B publishes (source = LWC B) 
5.  LWC A receives 
6.  LWC A updates UI 
7.  No recursion 

#Lightning Web Components  #Lightning Message Channel  #Salesforce Developer  #Issues