-
Notifications
You must be signed in to change notification settings - Fork 69
Description
Describe the bug
When using the botium-connector-webdriverio connector the moment a bot DOM element is appended Botium marks it as “new response”, extracts the message and proceeds — even when that element’s innerText is still empty or mid-animation. Result: intermittent assertion failures because Botium captured an empty/partial message and then the UI later fills the text (animation / typing effect). This happens even when WEBDRIVERIO_OUTPUT_ELEMENT_TEXT / WEBDRIVERIO_OUTPUT_ELEMENT_DEBUG_HTML are set; capture behaviour is inconsistent between runs.
Botium Flavour: Botium CLI
Botium Core / Plugin Versions (from logs): Botium Core 1.11.15; botium-connector-webdriverio plugin v0.4.2.
Steps To Reproduce
Create a botium.json config using the webdriverio connector. Example capabilities:
{
"botium": {
"Capabilities": {
"CONTAINERMODE": "webdriverio",
"WEBDRIVERIO_URL": "https://",
"WEBDRIVERIO_INPUT_ELEMENT": "#composer-input",
"WEBDRIVERIO_INPUT_ELEMENT_MODE": "enter",
"WEBDRIVERIO_OUTPUT_ELEMENT": "div[aria-live="polite"][shape="standalone"] span.sc-1t4lziz-0",
"WEBDRIVERIO_OUTPUT_ELEMENT_TEXT": true,
"WEBDRIVERIO_OUTPUT_ELEMENT_DEBUG_HTML": true,
"WEBDRIVERIO_OUTPUT_ELEMENT_WAITFOR": 8000,
"WEBDRIVERIO_OUTPUT_ELEMENT_WAITUNTIL": "text",
"WEBDRIVERIO_OUTPUT_ELEMENT_MAXTRY": 50,
"WEBDRIVERIO_OUTPUT_ELEMENT_RETRY": 300
}
}
}
Write a convo script where the bot is expected to reply with a sentence containing certain keywords:
#me
Hello
#bot
TEXT_CONTAINS_ALL_IC keyword1|keyword2
Run the test with:
npx botium-cli run --config ./botium.json --convos ./spec --verbose
Observe the behavior:
The chatbot widget shows the full bot reply after a short animation/typing effect.
Botium detects the new message element immediately and extracts messageText before the innerText is fully rendered.
In logs you will sometimes see:
"messageText": ""
even though the text appears in the browser a moment later.
Assertions fail intermittently with errors like:
ASSERTION FAILED - Expected: ["keyword1","keyword2"] - Actual: ""
Actual behavior
Botium detects a new bot DOM element and immediately extracts message content. If the span’s innerText is not yet populated (still animating), Botium captures "" and proceeds; this leads to assertion failures (expected text not present). Example: assertion error at Line 14/24 complaining expected tokens but actual messageText was empty.
Behaviour is intermittent: some runs capture final text/HTML correctly; others capture empty text. See alternating log entries where in one run messageText is filled and in another run the same step yielded empty messageText.
Expected behavior
The connector should wait until the message is fully rendered (ie. the span’s innerText is non-empty and stable) before extracting message text/HTML and returning BotSays.
WEBDRIVERIO_OUTPUT_ELEMENT_TEXT should be respected consistently: when false the connector should validate assertions against the HTML (sourceData.html), and when true it should validate text only. The field should not produce inconsistent messageText or html values across runs.
Screenshots and Log files
botium-output_1.txt
botium-output_2.txt
botium-output_3.txt
botium-output_4.txt
Botium Flavour: Botium CLI
Botium Core / Plugin Versions (from logs): Botium Core 1.11.15; botium-connector-webdriverio plugin v0.4.2.
Root cause (analysis)
Timing / race condition: connector’s polling loop detects the bot message element as soon as the DOM node is appended. The UI uses animations/typing effects that append the element first, then populate innerText progressively. Botium captures the element before the innerText is populated (or before animation completes), so getText() returns empty string. That matches the log pattern: “Found new bot response element” → immediately getBotMessageDefault receiving text for element → BotSays messageText:"".
Extraction flag inconsistency: WEBDRIVERIO_OUTPUT_ELEMENT_TEXT and WEBDRIVERIO_OUTPUT_ELEMENT_DEBUG_HTML are intended to control extraction mode, but logs show inconsistent items in sourceData.html vs messageText. This is likely because the connector:
a) sometimes runs a getText() and gets text, or
b) sometimes runs getHTML() (outerHTML) depending on element state, or
c) returns early if element exists even if waitFor/waitUntil conditions are not guaranteeing non-empty text.
The combination leads to inconsistent outcomes across runs.
WAITUNTIL semantics are insufficient: config options like WEBDRIVERIO_OUTPUT_ELEMENT_WAITFOR and WEBDRIVERIO_OUTPUT_ELEMENT_WAITUNTIL appear to wait for element existence or clickable/displayed, but they do not guarantee that the element’s innerText is non-empty or stable after animations. The connector needs a text non-empty / stable wait condition.