botkit: convo.ask and convo.addQuestion is not waiting for response in latest version

Or vice versa - are message_received and facebook_postback the only events we DO want included?

Thanks for your patience, folks. I’ll include a fix for this issue in the next release.

@Taichou good investigation!

I believe the solution is to exclude the message_delivered events from conversations. This will allow the other event types to be included.

Are there other event types that should ALWAYS be excluded from a conversation?

Actually… I’m not sure it’s a bug :p ! I think I got it:

it’s triggered by “message_delivered” and “message_read” both contain a text field that’s empty which is a falsy value, so it goes into the “else” and ends the conversation with a “Yes”. And even if they didn’t contain the text field, it will have the same result since null and undefined are both falsy values too.

The code should be something like this:

    convo.addQuestion("is it a bug?", (response, convo) => {
      if (response.text) {
        convo.say("No");
        convo.next();
      } else {
        console.log(
          "Not a bug: we've just received a " +
            response.type +
            ". So, no convo.next() here if we wanna still wait for an answer"
        );
      }
    });

When I run this code I get this log: Not a bug: we've just received a message_read. So, no convo.next() here if we wanna still wait for an answer

So, yea, it did wait for an answer just not the one we’re expecting.

Or I guess you can also unsubscripe to the webhooks message_deliveries, message_reads (not what I would do though).

That being said, this runs if require_delivery=false in case it’s true there is no answer but I’m guessing that’s another issue (see here: #643 ).

Hello guys, I’m facing the same problem with a bot on Facebook (running 0.6.2) and I’m thinking the conversation is triggered by the message_delivery. So, I tried reproducing it with a straightforward bot, and change the require_delivery value:

const Botkit = require("botkit");
const controller = Botkit.facebookbot({
  stats_optout: process.env.BOTKIT_OPTOUT,
  validate_requests: process.env.BOTKIT_VALIDATE_REQUEST, 
  access_token: process.env.FB_PAGE_TOKEN,
  verify_token: process.env.FB_VERIFY_TOKEN,
  app_secret: process.env.FB_APP_SECRET,
  debug: true,
  require_delivery: true
});

const bot = controller.spawn({});

controller.setupWebserver(process.env.PORT || 3000, function(err, webserver) {
  controller.createWebhookEndpoints(controller.webserver, bot, function() {
    console.log("This bot is online!!!");
  });
});

controller.hears(["hello"], "message_received", function(bot, message) {
  bot.reply(message, "Hey there.");
});

controller.hears(["question"], "message_received", function(bot, message) {
  bot.createConversation(message, (err, convo) => {
    convo.addQuestion("is it a bug?", (response, convo) => {
      if (response.text) {
        convo.say("No");
        convo.next();
      } else {
        convo.say("Yes: " + response.text);
        convo.next();
      }
    });
    convo.activate();
  });
});

• In case require_delivery=false: – Whenever the user sends Hello I get the reply. (Just a check). – Sending “question” leads to reproducing @gcfabri’s issue screen: Not waiting

• In case require_delivery=true: – Hello still working. – Sending “question” stops everything, even sending a hello afterward doesn’t work: screen: No answer I still receive the messages server-wise but no message is sent:

  debug: RECEIVED MESSAGE debug: CUSTOM FIND CONVO 1********* 1********* debug: FOUND EXISTING CONVO! debug: HANDLING MESSAGE IN CONVO

  then nothing happens.

Subscriptions wise this basic bot had every and any possible subscription (I didn’t give it too much thought):

Selected events: messages, messaging_postbacks, messaging_optins, message_deliveries, message_reads, messaging_payments, messaging_pre_checkouts, messaging_checkout_updates, messaging_account_linking, messaging_referrals, message_echoes, standby, messaging_handovers, messaging_policy_enforcement

Not sure if all this helps, in a nutshell: I reproduce the same bug :p