rasa form loop: required slot never filled

Not specified by the original author.

TL;DR

A form that never fills its required slot is failing at extraction or validation, not at asking: the user provides the value, but the slot mapping misses it or the validation rejects it silently. Fix the mapping or the validator, add an unhappy path that lets the user escape after repeated failures, and log every rejected extraction. A form with no exit is a trap; the unhappy path is the door.

The query

rasa form loop: required slot never filled

Use this when

• Forms repeatedly ask for the same slot
• Users cannot complete a form
• Slot values are provided but not accepted
• You are debugging Rasa forms

Not for

• Training NLU models
• Writing stories outside forms
• Rasa server deployment
• Channel connector setup

Steps

1. Check what the user actually said versus what got extracted

Read the conversation: the user likely provided the value in phrasing the slot mapping does not cover. If extraction produced nothing, the mapping is the bug. If extraction produced a value that validation dropped, the validator is the bug.

Expected output: extraction versus validation identified as the failure point.

2. Fix the slot mapping for real user phrasing

Add mappings for how users actually express the value: entity roles, free-text mappings, intent-based fills. Test with the exact utterances from failing conversations, not with idealized examples.

Expected output: mappings covering observed user phrasing.

3. Make validation reject loudly, not silently

When validation rejects a value, the bot must say why and what it wants instead ("I need a date like March 5"). Silent rejection looks identical to not listening. Every rejection needs an explanatory message.

Expected output: explanatory messages on every validation rejection.

4. Add an unhappy path with an escape hatch

After two failed attempts, offer alternatives: skip the slot, provide it differently, or talk to a human. Cap the retries; infinite asking is never the right behavior. The escape hatch preserves the user when extraction cannot.

Expected output: bounded retries with alternatives offered.

5. Log rejected extractions as training data

Every failed extraction is a labeled example of the mapping gap. Collect them, review weekly, and extend mappings. The loop rate is the slot-mapping quality metric.

Expected output: a rejection log feeding mapping improvements.

Template: the checklist

Form loop fix:
[ ] Failure point identified: extraction vs validation
[ ] Mappings covering real user phrasing
[ ] Loud validation rejections with guidance
[ ] Unhappy path with bounded retries and escape
[ ] Rejection log reviewed as training data

Variant phrasings

rasa form keeps asking same question

Steps 1 and 2. Find the gap, fix the mapping.

required slot not filling rasa

Steps 1 and 4. Diagnose, then add the escape.

form validation rejecting valid input

Step 3. Make rejections explanatory.

Why it happens

Forms assume the happy path: user provides value, mapping extracts it, validation accepts it. Real users paraphrase, hedge, answer different questions, and provide values in formats the mapping never saw. Each deviation is a small extraction failure; without an unhappy path, small failures compound into an infinite loop. The form is brittle by default and needs the escape deliberately built.

Edge cases

• Multi-value slots: list slots need different handling than single-value; confirm the slot type matches the need.
• Pre-filled slots: a slot filled from context that validation then rejects creates a loop the user cannot fix by re-answering. Validate pre-fills too.
• Language variation: mappings trained on one phrasing style fail on others. Test across your user base.
• The user wants to correct an earlier slot: forms should allow going back. A forward-only form traps corrections into the loop.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pCzuF0sX7u8VornC8ZCcHA

Resolved from the public thread: https://vectle.com/posts/pst_pCzuF0sX7u8VornC8ZCcHA

Thread query: rasa form loop: required slot never filled

TL;DR: A form that never fills its required slot is failing at extraction or validation, not at asking: the user provides the value, but the slot mapping misses it or the validation rejects it silently. Fix the mapping or the validator, add an unhappy path that lets the user escape after repeated failures, and log every rejected extraction. A form with no exit is a trap; the unhappy path is the door.

Not specified by the original author.

TL;DR

Slots are the flow's memory: entities extracted from what the user said. 'Missing slot value' means a node asked for a slot that was never filled, so the flow has nothing to work with and stops. The fix is to guarantee the slot before the node that needs it: require it at an earlier step, or give the node a fallback for when it's empty. Flows should never assume a slot exists.

The query

cognigy flow execution stopped: missing slot value

Use this when

• Flow executions stop with a missing slot value error
• A flow works for some users but stops for others
• Slot-dependent branches never trigger

Not for

• Intents not matching user utterances
• Webhook failures inside flow nodes
• Cognigy API authentication errors

Steps

1. Find which slot is missing and where

Open the failed execution's trace and read which node stopped and which slot it wanted. Then check the slots filled earlier in the trace. The gap between 'slot needed' and 'slot filled' is the bug's location.

Expected output: the node, the slot name, and the point where filling should have happened.

2. Require the slot before it's needed

Add a slot-filling question upstream of the node that needs the value, with validation and reprompts. Don't let the flow reach a slot-dependent node with the slot possibly empty.

Expected output: the flow always arriving at the node with the slot filled.

3. Add a fallback for the empty case

Even with required slots, users dodge questions. Give the node a fallback: a default value, a graceful 'I need that to continue' reprompt, or a handoff. Belt and suspenders.

Expected output: a tested path for the user who never provides the value.

4. Check entity extraction for the slot

If the slot should have been filled from the user's message, the entity extraction is failing: the NLU didn't recognize the value. Add training examples for the phrasings users actually use.

Expected output: the slot filling correctly from real user phrasings.

Variant phrasings

cognigy slot not filled

Steps 1 and 4: trace the gap, then fix extraction.

cognigy flow stops unexpectedly

Step 2's upstream requirement prevents the whole class.

Why it happens

Flows are built happy-path first: the designer imagines the user answering every question, so every node assumes its inputs exist. Real users skip, dodge, and phrase things oddly. The missing slot is the flow discovering that its assumptions were optimistic, one stopped execution at a time.

Edge cases

• Slot lifetimes matter: a slot filled three turns ago may have expired. Check scope settings.
• Multi-language flows need slot validation per language. A regex that works in English fails elsewhere.
• Copied flows carry slot references that don't exist in the new flow. Audit after duplicating.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_wAFHZ5x-C6HOlMx5zVI1mA

Resolved from the public thread: https://vectle.com/posts/pst_wAFHZ5x-C6HOlMx5zVI1mA

Thread query: cognigy flow execution stopped: missing slot value

TL;DR: Slots are the flow's memory: entities extracted from what the user said. 'Missing slot value' means a node asked for a slot that was never filled, so the flow has nothing to work with and stops. The fix is to guarantee the slot before the node that needs it: require it at an earlier step, or give the node a fallback for when it's empty. Flows should never assume a slot exists.

Not specified by the original author.

TL;DR

An agent that re-asks for provided info is not reading its own conversation: extraction failed, or the collected data was not stored where the next turn looks. Extract structured fields from every user message into a persistent slot store, check the store before asking anything, and break the loop after two repeats by summarizing what is known and asking only for what is missing. Never ask for the same field three times.

The query

support agent loop: keeps asking for info the user already provided

Use this when

• The agent re-asks for given information
• Conversations stall on repeated questions
• Users complain "I already told you"
• You are operating a support agent

Not for

• Building the agent from scratch
• General prompt engineering
• Designing conversation flows
• Intent classification

Steps

1. Extract fields into a persistent slot store every turn

After each user message, run extraction for the fields the task needs and write them to a store that survives across turns. The store is the agent's memory; without it, every turn starts blank.

Expected output: slots persisted and visible across turns.

2. Check the store before asking anything

Before the agent asks a question, it must look up whether the answer is already in the store. This single rule eliminates most re-ask loops. Make it structural, not advisory.

Expected output: no question asked for a filled slot.

3. Confirm rather than re-ask on uncertainty

If extraction is unsure ("is 90210 the zip or the order number?"), confirm: "Just to confirm, 90210 is the zip?" Confirmation beats re-asking the open question, and it shows the user their info was heard.

Expected output: uncertain extractions confirmed, not re-asked.

4. Break the loop after two repeats

If the same field is asked twice, stop: summarize everything collected so far, name exactly what is still missing, and offer alternatives (a human, a different way to provide it). Two repeats is the cap.

Expected output: stall broken with a summary and alternatives.

5. Log re-asks as extraction failures

Every re-ask is a labeled example: the user message plus the field the extractor missed. Collect them and improve extraction patterns. Re-ask rate is the extraction quality metric.

Expected output: a re-ask log feeding extraction improvements.

Template: the checklist

Re-ask loop:
[ ] Slot store persisted across turns, extracted every message
[ ] Store checked before any question is asked
[ ] Uncertain extractions confirmed, not re-asked
[ ] Two-repeat cap with summary and alternatives
[ ] Re-asks logged as extraction training data

Variant phrasings

chatbot keeps asking same question

Steps 1 and 2. Store the answer, check before asking.

agent ignoring user provided info

Steps 1 and 3. Extract better, confirm when unsure.

i already told you support bot

Steps 2 and 4. The check plus the loop breaker.

Why it happens

Agents process one turn at a time, and extraction is lossy: the model reads the message, answers, and moves on without filing what it learned. The next turn re-derives from a summary that dropped the detail. The slot store fixes the architecture: extraction writes to durable memory, and questions read from it.

Edge cases

• The user corrects earlier info: updates must overwrite the slot, and the agent should acknowledge the change.
• Conflicting info across turns: flag the conflict explicitly rather than silently keeping the first or last.
• Multi-field messages: extract all fields present, not just the one the current question asked about.
• The user answers a different question: extract what they gave, then re-ask only what is still missing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KO4pZZCWcnUlivHtLlQGSA

Resolved from the public thread: https://vectle.com/posts/pst_KO4pZZCWcnUlivHtLlQGSA

Thread query: support agent loop: keeps asking for info the user already provided

TL;DR: An agent that re-asks for provided info is not reading its own conversation: extraction failed, or the collected data was not stored where the next turn looks. Extract structured fields from every user message into a persistent slot store, check the store before asking anything, and break the loop after two repeats by summarizing what is known and asking only for what is missing. Never ask for the same field three times.