Suggested Questions After Answer#

Suggested Questions After Answer is a Dify chat feature that automatically generates follow-up question suggestions after each AI response. When enabled, a client calls a dedicated API endpoint to retrieve a list of LLM-generated questions based on recent conversation history.

The feature is only available for chat-based app modes: CHAT, AGENT_CHAT, ADVANCED_CHAT, and AGENT 1. It is not supported for COMPLETION or WORKFLOW apps.

Configuration Schema#

The feature config is a SuggestedQuestionsAfterAnswerConfig TypedDict with these fields 2:

Config is stored and read differently by app mode:

• Basic Chat / Agent-Chat: stored in AppModelConfig.suggested_questions_after_answer DB column; read via the suggested_questions_after_answer_dict property.
• Advanced Chat: stored in Workflow.features_dict["suggested_questions_after_answer"]; read through AdvancedChatAppConfigManager.get_app_config() 2.
• Agent: resolved at runtime via AgentRuntimeConfigService (see Runtime Flow below).

Validation is handled by SuggestedQuestionsAfterAnswerConfigManager: validate_and_set_defaults() enforces types and length limits, defaulting the entire block to {"enabled": False} if absent.

Runtime Flow#

MessageService.get_suggested_questions_after_answer() orchestrates the request:

1. Fetch & validate — confirms the message belongs to the requesting user.
2. Read feature config — branches on app_model.mode:
   • Advanced Chat: reads from the draft or published workflow's features_dict. Raises SuggestedQuestionsAfterAnswerDisabledError if absent.
   • Agent: resolves via AgentRuntimeConfigService in priority order — debug draft → bound snapshot → published soul → legacy AppModelConfig 2.
   • Chat / Agent-Chat: reads AppModelConfig.suggested_questions_after_answer_dict. If the conversation has override_model_configs, normalizes through Conversation.model_config to handle legacy config shapes 3.
3. Generate — calls LLMGenerator.generate_suggested_questions_after_answer() with conversation history. The generator uses the configured override model if provider and name are valid strings, falling back to the tenant's default LLM on any exception 4.
4. Trace — emits a SUGGESTED_QUESTION_TRACE to the ops trace queue.

LLM Invocation Details#

• The prompt is assembled by SuggestedQuestionsAfterAnswerOutputParser using the custom instruction or the built-in default prompt.
• For the default model path, parameters are built by _default_suggested_questions_model_parameters(): caps max_tokens at 256, sets temperature to 0.0, and attempts to disable reasoning by setting thinking=False/"disabled" or choosing the lowest available reasoning_effort (none → minimal → low).
• For the configured-model path, completion_params from config are passed as-is after normalizing stop and dropping non-positive token limits 5.
• The LLM call is wrapped with a hard 30-second plugin-daemon timeout via use_plugin_daemon_request_timeout(30.0) 6. Any exception returns [] — the feature degrades silently.
• Output is parsed by SuggestedQuestionsAfterAnswerOutputParser.parse(), which extracts a JSON array from the response text.

API Endpoints#

All endpoints gate on app mode and return 400 bad_request with "Suggested Questions Is Disabled." if the feature is not enabled 7.

Known Issues & Fixes#

Reasoning models silently break the feature#

When the workspace System Model is a reasoning model (DeepSeek-R1, o1, etc.), the internal thinking process consumes all available output tokens, leaving nothing for the JSON array output. The feature returns an empty list with no user-facing error 8.

Fix (merged, PR #41705): _default_suggested_questions_model_parameters() now inspects the model schema and disables reasoning where supported, plus adds the 30-second hard timeout. If the configured/default model cannot be resolved, the service returns [] rather than raising 9 10.

An earlier open PR #34652 11 proposed stripping <think>…</think> blocks in the output parser as an additional guard, but the merged fix in PR #41705 addresses the root cause by disabling reasoning at the model parameter level.

Legacy override configs cause 500 errors#

Older conversations with override_model_configs missing newer required fields caused Pydantic 500 errors. Fixed (PR #36459) by routing through Conversation.model_config for compatibility normalization rather than parsing override_model_configs directly.

Agent apps: missing AppModelConfig#

Agent debug conversations intentionally store app_model_config_id = NULL. The prior code path (shared with Basic Chat) raised ValueError("did not find app model config") (HTTP 500). Fixed by introducing the AgentRuntimeConfigService resolution path (PR #40963).

Agent v2: legacy model shape rejected#

Agent v2 apps rejected the { provider, name, mode, completion_params } model shape in suggested_questions_after_answer.model. Fixed (PR #38370) by introducing AgentSuggestedQuestionsAfterAnswerModelConfig in api/models/agent_config_entities.py.