MessagingService.Ready event bug?

Web Messaging
1

Anybody got issues today where it appears the MessagingService.Ready event is not being received/sent after subscribing to it?

2

Hi @VaunMcCarthy,

I'm not sure when this is happening for you, but let me try explaining how it works.

  1. If you are hiding the Messenger UI with using Headless SDK (Messenger UI hidden), MessagingService.Ready event is always published that you can subscribe to and call its commands to use it for building your own UI.

  2. If you are using our native Messenger UI, MessagingService.Ready event will be published only when this plugin is lazy loaded. This can happen in one of the following ways:

  • When you open Messenger either by command Messenger.open or by clicking on the Launcher button, that lazy loads the MessagingService plugin publishing its ready event.
  • Or when there is any active Conversation already, Messenger auto loads the MessagingService plugin publishing its ready event.

May I know what is your case here? If this doesn't address your issue, please let me know what your configuration looks like so we can look into it.

3

Interesting thanks. That's actually the opposite of how my client believed it works. The team had been working on the assumption that an issue we have with the launcher button not appearing was because we weren't getting the ready event.

But based on what you're saying we likely never will get it without actually having the launcher there and opening it. That also explains why we can get the launcher to show if we inject messaging open via browser console. Although what is being raised is that there's some belief/confidence that the subscribe command is being sent but we're not seeing that subscribe request in the console log. Which should ultimately be irrelevant?

We are using a custom button but standard UI.

Just so I understand things correctly though, once I subscribe to something like messagingservice.ready, that js code and websocket will "run in the background" waiting to hear that ready event then call the function(s) specified in the initial subscribe command - meanwhile all other code on page runs? Am I correct?

4

The MessagingService.Ready "issue" may have lead us down the wrong path here. Console logs show and error trying to register the AuthProvider plugin with an error that Name is already taken. That failure may in turn be leading to other issues.

5

Hi Ranjinth.

That is very useful information. We have passed it to our customer but they have questioned why this information is not included in the official API documentation. Their argument is that the behaviour of the MessagingService.Ready event seems to have changed a few days ago (previously they were using this event to display the launcher, but now it isn't generated until after the launcher has been clicked) and so they want to validate the new behaviour before they go to the trouble of redeveloping their application to work with the new behaviour.

Is it possible to get the official documentation updated to include the lifespan of the various Web Messenger objects?

Thanks,
Nick.

6

Hi @Nick_Tait, if I'm understanding correctly, customer was using MessagingService.ready event to show their own Launcher button? Any reason why it was done that way? Because all they need here is to subscribe to Messenger.ready event (here, I assume customer is using our native Messenger UI) and show Launcher button.

We will add this info in our MessagingService plugin so its clear going forward.

7

Hi Ranjith.

I think they misunderstood the purpose of the different objects, and so they essentially implemented the logic to display the launcher in the wrong place.

I've forwarded your advice to them, and if the documentation can be made clearer I think they will be happy.

Thanks very much,
Nick.

8

Our customer has asked whether there is a particular event that they need to wait for before issuing a Database.set command?

Nick.

9

@Nick_Tait Yes, it will be Database.ready event. This should have been documented in the Database plugin, but looks like it is missing. We will include this there. A general thumb rule is to subscribe to that plugin ready event before calling its commands.

10

Hi Ranjith

Judging by your response on the other thread, we seem to be back at our original problem which is that up until Tuesday of last week, our client believes they were receiving the messagingservice.ready event BEFORE the launcher button had been clicked or presented. No code/script/configuration/deployment changes took place in the org prior to the behaviour changing. It just stopped acting one way "overnight".

I was hoping that the other issue you've identified and fixed had been related so we now still need to find out a) why it seemed to work contrary to how you described it prior to last week, b) confirmation that messagingservice.ready should not be expected prior to the end-user seeing and clicking on the launcher button, and c) that the order of events we should potentially be considering is listening for messenger ready first, then display the launcher, then when launcher is ready listen for messagingservice.

Although also as Nick has pointed out, likely we also need to listen for the undocumented database.ready event. At what point in the event and flow of things would we normally expect the database.ready event to fire and can start sending commands to it? Are we correct in our understanding that database.set loads any attributes into "cache" and then attaches those through to Genesys Cloud upon a subsequent inbound message? If so - what constitutes an "inbound message" in this context?

11

@VaunMcCarthy I think I may have now understood the issue you are facing. I wasn't completely aware of your use-case earlier, that you have Authentication is enabled in your configuration but still MessagingService.ready event is not published. Is that correct? This looks like a bug on our end and we are fixing it right away.

In my above comment here, under #2 this should also be added:

  • When Authentication is enabled, MessagingService plugin will always be loaded and publishes MessagingService.ready event.
12

About the Database.ready event, your understanding is correct. It a plugin that will always be fired at the start-up of Messenger (no additional conditions) and be ready to accept commands. Any data that you attach, will be cached and sent along in the next subsequent inbound message. And "inbound message" will be any message (any text message or an attachment) that a user sends from Messenger.

13

There is still an issue on Messager.ready
The first time it triggers, We can't use commands

Here the code where I open the Messager when plugin is ready:
Genesys("subscribe", "Messenger.ready", function({data}){
Genesys("command", "Messenger.open");
});

This leads to this logs:
Messenger published: ready%c
genesys.min.js:10 'MessagingService' plugin not currently registered. Attempting to load plugin from configured path (https://apps.mypurecloud.ie/genesys-bootstrap/plugins/).
genesys.min.js:10 Loading plugin: messagingservice.min.js
cxbus.min.js:6 Genesys called the command: Messenger.open%c
cxbus.min.js:6 Error (Messenger.open):
cxbus.min.js:6 Command does not exist

It was working at the beginning of September (before 12)

14

Thanks Ranjith that's slightly "better" news. Have you confirmed on your end that this bug was introduced around the 12/13 of the month and do we know what introduced that bug? When would a fix likely be deployed?

Do we know if that bug has been communicated out to the various teams including @Care?

Also, is work being done to improve the dev docs overall to capture some of what you've helped us be aware of in this thread?

15

Hi @VaunMcCarthy, yes the bug was introduced from our deployment that happened on 12th, which was due to Messenger improvements that shouldn't have caused this issue. The fix is now deployed. Please check now.

We are working to know how we can communicate this bug to various team. I will be letting the care team know later today. About docs, yes we will work on improving them.

16

Thanks Ranjith, it's unfortunate that this whole exercise has taken a week to get to this point

There will no doubt be separate discussions but how is it that this issue wasn't picked up in any regression testing on your side? It seems like the dev/servops group that care go through are operating on a different communication timeline otherwise I would have hoped our escalated case would have immediately triggered a response as soon as that defect was confirmed and the fix scheduled.

Was this an actual fix or a roll-back of the deployment from last week? How confident are you that we are now in a stable situation?

Regarding the release itself last week - why don't we see any reference to that on any release notes or announcement boards? Something like that would have helped immensely in our initial triage if we'd been aware that there were changes released outside of what's on the public release notes pages.

On the comms thing, again there will be separate discussions but can we please work on improving the lines of communication between the care team and devops so that there's some type of broadcast or pinned post situation thing? You indicated to me a few days ago that this looked to be a confirmed defect, and obviously there have been developers actively working on the fix but we've had effectively no update of substance in our case itself.

17

Hi @VaunMcCarthy,

I confirmed this as defect here only after looking at your immediate previously response indicating use-case that Auth is enabled in the configuration. And then the fix was immediately deployed in a day. I think prior to this in my initial post in this thread, this was my first question. Once we know, the fix was immediately deployed.

I agree it’s unfortunate that this wasn’t caught in our regression and we are working on improving that.

About the fix, it’s an actual fix that I’m pretty confident, not rollback.

18

Vaun - first of all: the product misbehaved, in some very specific conditions, and that's on us to fix and ensure it doesn't happen again.

Having said that, for clarity:

  • We don't announce internal architectural improvements, unless these are meant to have a visible impact to our customers. In this case, no impact was planned.
  • I want to be sure this developer community is not being used as a shortcut to regular Customer Support procedures: raising potential issues or posting Case tickets here is not meant to speed-up regular Genesys Care support and SLAs.
  • Nevertheless, defects were fixed same day as we acknowledged them.

Thanks for all your active contribution, it will help us further improve the product moving forward.

19

For information, I have just retested today and it is fixed
Now the messager.ready is launched only twice and there is no more error

20

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.