I have race condition when acdl event is pushed and added as event type , the custom code block even first line of console log doesnt execute and it throws a timeout error

[KalaivaniL4]

In my website , I see a race condition rarely when the user land on first load rarely i could see my web sdk page load rule is not triggering. So i created an rule checking whether the acdl, ecid and one trust is available and emitting an acdl event on its availability. But this rule checking throws a timeout error on a race condition first page load where it records a unique visitor but not the pageview.
We are triggering that checking rule on acdl event pageloaded, but also throwing race condition and says custom code has been time out.
Any help how this can be fixed.
Note : Will this be caused as when acdl is pushed before launch library is not ready
please advise

[bjoern__koth]

Hi @KalaivaniL4 

by any chance, can you add screenshots? Having a hard time following your setup.

[KalaivaniL4]

this is the error which i am getting on a race condition, inside this custom code i have first line console log even that isnt printing.It didnt even get into custom code to emit pageload ready event which needs to triggered for page load rule

[Jennifer_Dungan]

Oh, so you are halting progress on tracking until users interact with your OneTrust logic... 

I don't think a timeout change here is the best option...

I am wondering if you should split up the logic... 

If the user is opted-in, run a rule that has an Opt-In condition on the DOM Ready or whatever page trigger you have. I would also add a second "Direct Call" trigger on this rule. Something like:

If the user is not opted-in, then the rule won't fire when the page loads, and if they are, then it will run.

Then, you need a second rule that is tied to the action of opting-in... when the user opts-in (which will be far past the DOM Ready state), you can call the Direct Call trigger using:

_satellite.track('opt-in-action');

So the user will opt-in, have the opt-in condition, and trigger the tracking rule...

Nothing is sitting there waiting for something to happen and timing out.

[KalaivaniL4]

We are not waiting for one trust login but we are trying to resolve when the user lands from campaign page sometime race condition occur where the timeout occurs and not triggering the page load rule. Hence they developed another rule to verify whether the adobe analytics ecid, onetrust, is ready then to emit an acdl event global pageload event ready which can resolve the timeout issue which is happening in the website, so hence unique visitor counts 1 and there is no pageview hit which 0 for few ecid hence created an rule to emit an event then to trigger the pageload event.

[Jennifer_Dungan]

Ok, I see... but since we don't have access to see your code, know how the pieces fit together or see it in action, this will be very hard to diagnose...

Have you reached out to your site developers? Maybe they can help with the coding and support the issue you are facing?

Or if you can provide more info about what is happening, we can try our best to help... but there's so many unknowns for us right now... 

Right now, all we can see if that there is a 30 second timeout.. and I can see an unresolved OneTrust banner... which is why I thought this was what you were waiting on (for the user to accept or reject)

[bjoern__koth]

Hi @KalaivaniL4 

that's a lot of code to fight symptoms but not necessarily the root cause.

Maybe a couple of things and side notes:

1. the ECID must not ne acquired unless consent is given, since it writes a cookie. -> fix asap

If you want to map the ECID to analytics variables, this should be done in the datastream mapping instead, as described here.

If you need the value in conjunction with other Launch logic, it has to be executed upon consent change.

2. Consent handling within the Web SDK

Like the legacy Visitor ID Service, the Web SDK is capable of handling consent for the Adobe tools.

It uses an internal queue that releases the queue once consent is given.

To use this queue, make sure that the Consent is set to "Pending" in the Web SDK extension settings.

Upon given consent, there is a dedicated "set-consent" action in the extension for that.

This comes with an implication that usually you won't have to add consent checks in the rule conditions that trigger Adobe tools (make sure to not mix up Adobe tools with other 3rd party tags in rules).

3. OneTrust consent changes and Web SDK "set-consent"

I would typically recommend an approach with two rules.

1. a "library loaded" rule with a custom code that registers a OneTrust OnConsentChanged handler and triggers an event (if you use a direct call rule or ACDL event is completely up to you)

const consentInterval = setInterval(() => {
    // check if loaded
    if (typeof window?.OneTrust?.OnConsentChanged === "function") {
        clearInterval(consentInterval);
        window.OneTrust.OnConsentChanged(() => {
            _satellite.logger.debug(">>> Consent: consent_changed");
            adobeDataLayer.push({
                "event": "consent_changed"
            });
            // alternatively through a direct call
            // _satellite.track("consent_changed");
        });
    }
}, 250);

    2. a rule that listens to this event and calls Web SDK "set-consent" action if the user has given consent for the analytics/performance consent category. (Since you do not seem to have the RT-CDP, you will likely be ok with the Adobe consent 1.0). As mentioned, this will release the queued tracking calls.

More documentation on this matter can be found here.

experienceleague.adobe.com/en/docs/platform-learn/implement-web-sdk/consent-management/setup-consent...

https://experienceleague.adobe.com/en/docs/experience-platform/web-sdk/commands/setconsent#

The point of having a tag manager that uses vendor extensions should be keeping the amount of custom code to a minimum.
I think / would hope your issue lies somewhere in the slightly overengineered setup.