[Draft] Bootstrap & Upgrade: new status & diagnoses endpoint for main components

[634750802]

Motivation

We need a more effective bootstrap/upgrade procedure for autoflow users.

Design

Provide diagnose and status API for main components:

• Chat Engine
• Knowledge Base

There are 3 levels of diagnose messages:

• required: If exists any, the component will not be available.
• deprecated: Something was deprecated and will be unsupported in future version.
• recommended: Some advises for best practice.

Backend

Admin diagnoses API

GET /api/admin/v1/{component}/diagnoses

{
  "required": ["foo", "bar"],
 ...
}

Client status API

GET /api/v1/{component}/status

{
  "available": true | false
}

Clients

• Clients should not execute Chat API when selected chat engine was not available.
• Clients should not execute KB retrieve API when selected kb was not available.

Chat Engine Diagnoses:

• required:
  • default_llm_not_configured: When no LLM selected for LLM or FastLLM and there is no configured default LLM.
• deprecated:
  • knowledge_base_not_configured: A message for old datasource (version <= 0.2) users.
• recommended:
  • default_reranker_not_configured: When no Reranker selected and there is no configured default Reranker.

Knowledge Base Diagnoses:

• required:
  • no_datasource: Knowledge Base has no datasource.
  • default_embedding_model_not_configured: ...
  • default_llm_not_configured: ...
  • no_document: ...

[Mini256]

GET /api/v1/{component}/status

I think the existing bootstrap status API is still reasonable, I don't really want the frontend to send a lot of check requests to confirm that each component is working properly after opening the backend management page, as this will result in longer initial page loading times.

[634750802]

GET /api/v1/{component}/status

I think the existing bootstrap status API is still reasonable, I don't really want the frontend to send a lot of check requests to confirm that each component is working properly after opening the backend management page, as this will result in longer initial page loading times.

This API will not block initial page loading.

In future versions, some core update may not break all Chat Engine or KB configurations (or other components). It will be used for progressive features developments.

Two scenes for this API:

• After admin selected chat engine on home page, disable action button until chat engine status passed
• JS widgets should wait status check passed to render