imcp 0.0.17 → 0.0.18

package/dist/core/validators/FeedValidator.js

@@ -1,5 +1,8 @@
+import fs from 'fs/promises';
 import { serverValidatorFactory } from "./ServerValidatorFactory.js";
 import { Logger } from "../../utils/logger.js";
+import { onboardStatusManager } from "../onboard/OnboardStatusManager.js";
+import { OnboardingProcessStatus } from "../onboard/OnboardStatus.js";
 /**
  * Validates feed configurations to ensure they meet required criteria
  */
@@ -7,12 +10,16 @@ export class FeedValidator {
     /**
      * Validates a feed configuration
      * @param config The feed configuration to validate
+     * @param categoryName The name of the category (feed name) for status updates
+     * @param operationType The type of operation for status updates
      * @returns true if valid, throws error if invalid
      */
-    validate(config) {
+    async validate(config, categoryName, operationType) {
         try {
+            await onboardStatusManager.recordStep(categoryName, operationType, `Starting feed validation for '${config.name}'`);
             Logger.debug(`Validating feed configuration: ${config.name}`);
             // Validate required fields
+            await onboardStatusManager.recordStep(categoryName, operationType, `Validating required fields for '${config.name}'`);
             if (!config.name)
                 throw new Error('Feed name is required');
             if (!config.displayName)
@@ -20,11 +27,13 @@ export class FeedValidator {
             if (!config.description)
                 throw new Error('Feed description is required');
             // Validate MCP servers array
+            await onboardStatusManager.recordStep(categoryName, operationType, `Validating MCP servers array for '${config.name}'`);
             if (!Array.isArray(config.mcpServers) || config.mcpServers.length === 0) {
                 throw new Error('Feed must contain at least one MCP server');
             }
             // Validate requirements if present
             if (config.requirements) {
+                await onboardStatusManager.recordStep(categoryName, operationType, `Validating requirements for '${config.name}'`);
                 for (const req of config.requirements) {
                     if (!req.name)
                         throw new Error('Requirement name is required');
@@ -34,12 +43,14 @@ export class FeedValidator {
                         throw new Error('Requirement version is required');
                 }
             }
+            await onboardStatusManager.recordStep(categoryName, operationType, `Feed validation successful for '${config.name}'`, undefined, OnboardingProcessStatus.VALIDATING); // Still in progress until all servers validated
             Logger.debug(`Feed configuration validation successful: ${config.name}`);
             return true;
         }
         catch (error) {
-            const errorMsg = `Feed validation failed: ${error instanceof Error ? error.message : String(error)}`;
+            const errorMsg = `Feed validation failed for '${config.name}': ${error instanceof Error ? error.message : String(error)}`;
             Logger.error(errorMsg);
+            await onboardStatusManager.recordStep(categoryName, operationType, `Feed validation failed for '${config.name}'`, undefined, OnboardingProcessStatus.FAILED, errorMsg);
             throw new Error(errorMsg);
         }
     }
@@ -47,12 +58,18 @@ export class FeedValidator {
      * Validates a single MCP server configuration using the appropriate validator
      * @param server The MCP server configuration to validate
      * @param config The feed configuration containing shared requirements
+     * @param categoryName The name of the category (feed name) for status updates
+     * @param operationType The type of operation for status updates
      * @returns true if valid, throws error if invalid
      */
-    async validateServer(server, config) {
+    async validateServer(server, config, categoryName, operationType) {
+        const feedName = config.name; // categoryName is the feedName in this context
+        const serverDisplayName = server.name;
         try {
-            Logger.debug(`Validating server configuration: ${server.name}`);
+            await onboardStatusManager.recordStep(categoryName, operationType, `Starting server validation for '${serverDisplayName}' in feed '${feedName}'`, server.name);
+            Logger.debug(`Validating server configuration: ${serverDisplayName} in feed ${feedName}`);
             // Validate basic required fields
+            await onboardStatusManager.recordStep(categoryName, operationType, `Validating basic fields for server '${serverDisplayName}'`, server.name);
             if (!server.name)
                 throw new Error('Server name is required');
             if (!server.description)
@@ -61,16 +78,53 @@ export class FeedValidator {
                 throw new Error('Server mode is required');
             if (!server.installation)
                 throw new Error('Server installation configuration is required');
+            // Validate schema file existence if schemas is defined
+            if (server.schemas) {
+                await onboardStatusManager.recordStep(categoryName, operationType, `Validating schema file for server '${serverDisplayName}'`, server.name);
+                try {
+                    // Assuming server.schemas is a relative path from the project root or a path that needs to be resolved.
+                    // For now, let's assume it's relative to the feed file's location or an absolute path.
+                    // If it's relative to the feed file, we might need the feed file's path.
+                    // For simplicity, let's assume it's a path that can be directly accessed.
+                    // If the schema path is relative to the feed config file, this logic will need adjustment.
+                    // For now, we'll treat it as a path that `fs.access` can check.
+                    // It's more likely that schema paths are relative to the feed definition file itself.
+                    // However, the task description implies `server.schemas` is a path to be checked.
+                    // Let's assume for now it's a path that should exist.
+                    // If the schemas are stored within the repo, their paths would be relative to the repo root.
+                    // During validation, we might not have the repo context directly here.
+                    // This needs clarification on how schema paths are resolved during validation.
+                    // For now, we'll proceed with a direct check.
+                    // If the schema is part of the feed package, its path might be relative to the package root.
+                    // Let's assume the path is resolvable from the current working directory or is absolute.
+                    // This part might need refinement based on where schema files are expected to be.
+                    // The task implies `server.schemas` is a string path.
+                    const schemaPath = server.schemas; // This path needs to be correctly resolved.
+                    // If it's relative to the feed file, we need that context.
+                    // For now, we'll assume it's a path that can be checked.
+                    // This might be an issue if it's relative to a file not yet in the repo.
+                    // Let's assume it's a path that should be resolvable.
+                    await fs.access(schemaPath);
+                    Logger.debug(`Schema file ${schemaPath} exists for server ${serverDisplayName}`);
+                }
+                catch (fileAccessError) {
+                    throw new Error(`Schema file '${server.schemas}' not found for server '${serverDisplayName}'.`);
+                }
+            }
             // Get the appropriate validator for this server type
+            await onboardStatusManager.recordStep(categoryName, operationType, `Obtaining specific validator for server '${serverDisplayName}'`, server.name);
             const validator = serverValidatorFactory.getValidatorForServer(server);
             // Perform mode-specific validation with feed config
-            await validator.validateServer(server, config);
-            Logger.debug(`Server configuration validation successful: ${server.name}`);
+            await onboardStatusManager.recordStep(categoryName, operationType, `Performing mode-specific validation for server '${serverDisplayName}'`, server.name);
+            await validator.validateServer(server, config); // This internal call won't have status updates unless modified too
+            await onboardStatusManager.recordStep(categoryName, operationType, `Server validation successful for '${serverDisplayName}'`, server.name, OnboardingProcessStatus.VALIDATING); // Still in progress until all servers validated
+            Logger.debug(`Server configuration validation successful: ${serverDisplayName}`);
             return true;
         }
         catch (error) {
-            const errorMsg = `Server validation failed: ${error instanceof Error ? error.message : String(error)}`;
+            const errorMsg = `Server validation failed for '${serverDisplayName}' in feed '${feedName}': ${error instanceof Error ? error.message : String(error)}`;
             Logger.error(errorMsg);
+            await onboardStatusManager.recordStep(categoryName, operationType, `Server validation failed for '${serverDisplayName}'`, server.name, OnboardingProcessStatus.FAILED, errorMsg);
             throw new Error(errorMsg);
         }
     }

package/dist/core/validators/StdioServerValidator.js

@@ -91,7 +91,9 @@ export class StdioServerValidator {
                 // Resolve npm module paths in arguments
                 Logger.debug('Resolving npm module paths in arguments');
                 const npmPath = requirement ? this._getRequirementFolderPath(requirement) : undefined;
-                finalArgs = args.map(arg => arg.replace(MACRO_EXPRESSIONS.NPMPATH, resolveNpmModulePath(npmPath)));
+                finalArgs = args.map(arg => arg
+                    .replace(MACRO_EXPRESSIONS.NPMPATH, resolveNpmModulePath(npmPath))
+                    .replace(/\\/g, '/'));
                 Logger.debug(`Resolved npm arguments: ${finalArgs.join(' ')}`);
             }
             else if (command === 'python' || command === 'python3') {
@@ -109,54 +111,104 @@ export class StdioServerValidator {
                 }
             }
             return await new Promise((resolve, reject) => {
-                Logger.debug(`Starting process with command: ${command} ${finalArgs.join(' ')}`);
-                // Set timeout for server startup test
-                const timeout = setTimeout(() => {
-                    const msg = 'Server startup test timed out after 10 seconds';
-                    Logger.error(msg);
-                    serverProcess.kill();
-                    reject(new Error(msg));
-                }, 20000);
-                // Start the server process
+                Logger.debug(`Starting process for server test with command: ${command} ${finalArgs.join(' ')}`);
+                const timeoutDuration = 20000; // 20 seconds for server startup test
                 const serverProcess = spawn(command, finalArgs, {
-                    stdio: ['ignore', 'pipe', 'pipe'],
+                    stdio: ['ignore', 'pipe', 'pipe'], // stdin, stdout, stderr
                     shell: true
                 });
-                let output = '';
-                let errorOutput = '';
-                // Collect stdout
+                let stdoutData = '';
+                let stderrData = '';
+                let settled = false;
+                const cleanupAndResolve = (value) => {
+                    if (settled)
+                        return;
+                    settled = true;
+                    clearTimeout(timeoutId);
+                    serverProcess.stdout.removeAllListeners();
+                    serverProcess.stderr.removeAllListeners();
+                    serverProcess.removeAllListeners('exit');
+                    serverProcess.removeAllListeners('error');
+                    if (serverProcess.exitCode === null && !serverProcess.killed) {
+                        serverProcess.kill();
+                    }
+                    resolve(value);
+                };
+                const cleanupAndReject = (err) => {
+                    if (settled)
+                        return;
+                    settled = true;
+                    clearTimeout(timeoutId);
+                    serverProcess.stdout.removeAllListeners();
+                    serverProcess.stderr.removeAllListeners();
+                    serverProcess.removeAllListeners('exit');
+                    serverProcess.removeAllListeners('error');
+                    if (serverProcess.exitCode === null && !serverProcess.killed) {
+                        serverProcess.kill();
+                    }
+                    reject(err);
+                };
+                const timeoutId = setTimeout(() => {
+                    if (settled)
+                        return;
+                    if (serverProcess.exitCode === null) { // Process is still running
+                        Logger.debug(`Server startup test: Process still running after ${timeoutDuration / 1000} seconds. Considering it successful.`);
+                        Logger.debug(`Collected stdout:\n${stdoutData}`);
+                        Logger.debug(`Collected stderr:\n${stderrData}`);
+                        cleanupAndResolve(true);
+                    }
+                    else {
+                        // Process exited before timeout, 'exit' handler should have caught it.
+                        // This is a fallback or race condition handling.
+                        const msg = `Server startup test: Process exited with code ${serverProcess.exitCode} before timeout completed.`;
+                        Logger.error(msg);
+                        Logger.debug(`Collected stdout:\n${stdoutData}`);
+                        Logger.error(`Collected stderr:\n${stderrData}`); // Log stderr as error here
+                        cleanupAndReject(new Error(msg + ` Stderr: ${stderrData}`));
+                    }
+                }, timeoutDuration);
                 serverProcess.stdout.on('data', (data) => {
-                    output += data.toString();
-                    // If we see any output, consider it a success
-                    clearTimeout(timeout);
-                    serverProcess.kill();
-                    resolve(true);
+                    const messageChunk = data.toString();
+                    stdoutData += messageChunk;
+                    Logger.debug(`Server stdout: ${messageChunk.trim()}`);
                 });
-                // Collect stderr
                 serverProcess.stderr.on('data', (data) => {
-                    errorOutput += data.toString();
+                    const messageChunk = data.toString();
+                    stderrData += messageChunk;
+                    // Log stderr, but it doesn't automatically mean failure.
+                    // The exit code or an 'error' event will determine failure.
+                    Logger.debug(`Server stderr: ${messageChunk.trim()}`);
                 });
-                // Handle process exit
-                serverProcess.on('exit', (code) => {
-                    clearTimeout(timeout);
-                    if (code !== null && code !== 0) {
-                        const msg = `Server startup failed with code ${code}: ${errorOutput}`;
+                serverProcess.on('exit', (code, signal) => {
+                    if (settled)
+                        return;
+                    Logger.debug(`Server process exited with code ${code}, signal: ${signal}.`);
+                    Logger.debug(`Final stdout:\n${stdoutData}`);
+                    Logger.debug(`Final stderr:\n${stderrData}`);
+                    if (code === 0) {
+                        cleanupAndResolve(true);
+                    }
+                    else {
+                        const msg = `Server process exited with non-zero code ${code} or signal ${signal}. Stderr: ${stderrData.trim()}`;
                         Logger.error(msg);
-                        reject(new Error(msg));
+                        cleanupAndReject(new Error(msg));
                     }
                 });
-                // Handle process error
                 serverProcess.on('error', (error) => {
-                    clearTimeout(timeout);
-                    const msg = `Server startup error: ${error.message}`;
+                    if (settled)
+                        return;
+                    const msg = `Server process failed to start or encountered an error: ${error.message}.`;
                     Logger.error(msg);
-                    reject(error);
+                    Logger.debug(`Stdout at error:\n${stdoutData}`);
+                    Logger.error(`Stderr at error:\n${stderrData}`);
+                    cleanupAndReject(new Error(`${msg} Stderr: ${stderrData.trim()}`));
                 });
             });
         }
         catch (error) {
-            const msg = `Failed to test server startup: ${error instanceof Error ? error.message : String(error)}`;
+            const msg = `Failed to test server startup (outer catch): ${error instanceof Error ? error.message : String(error)}`;
             Logger.error(msg);
+            // Ensure the error thrown is an instance of Error
             throw error instanceof Error ? error : new Error(msg);
         }
     }

package/dist/services/MCPManager.d.ts

@@ -5,9 +5,10 @@ export declare class MCPManager extends EventEmitter {
     private installationService;
     private configProvider;
     private feedOnboardService;
+    private schemaProvider;
     constructor();
     syncFeeds(): Promise<void>;
-    initialize(feedFile?: string): Promise<void>;
+    initialize(feedFile?: string, schemasDirectory?: string): Promise<void>;
     listServerCategories(options?: ServerCategoryListOptions): Promise<MCPServerCategory[]>;
     getFeedConfiguration(categoryName: string): Promise<FeedConfiguration | undefined>;
     getServerMcpConfig(categoryName: string, serverName: string): Promise<import("../core/metadatas/types.js").McpConfig | undefined>;

package/dist/services/MCPManager.js

@@ -1,5 +1,6 @@
 import { EventEmitter } from 'events';
 import { ConfigurationProvider } from '../core/loaders/ConfigurationProvider.js';
+import { ServerSchemaProvider } from '../core/loaders/ServerSchemaProvider.js';
 import { InstallationService } from './InstallationService.js';
 import { MCPEvent, } from '../core/metadatas/types.js';
 import { Logger } from '../utils/logger.js';
@@ -8,18 +9,21 @@ export class MCPManager extends EventEmitter {
     installationService;
     configProvider;
     feedOnboardService;
+    schemaProvider;
     constructor() {
         super();
         this.configProvider = ConfigurationProvider.getInstance();
+        this.schemaProvider = ServerSchemaProvider.getInstance();
         this.installationService = new InstallationService();
         this.feedOnboardService = new FeedOnboardService();
     }
     async syncFeeds() {
         await this.configProvider.syncFeeds();
     }
-    async initialize(feedFile) {
+    async initialize(feedFile, schemasDirectory) {
         try {
             await this.configProvider.initialize(feedFile);
+            await this.schemaProvider.initialize(schemasDirectory);
         }
         catch (error) {
             console.error("Error during MCPManager initialization:", error);

package/dist/services/ServerService.js

@@ -1,7 +1,7 @@
 import path from 'path';
 import { fileURLToPath } from 'url';
 import { Logger } from '../utils/logger.js';
-import { getServerSchemaProvider } from '../core/loaders/ServerSchemaProvider.js';
+import { ServerSchemaProvider } from '../core/loaders/ServerSchemaProvider.js';
 import { mcpManager } from './MCPManager.js';
 import { UPDATE_CHECK_INTERVAL_MS } from '../core/metadatas/constants.js';
 import { updateCheckTracker } from '../utils/UpdateCheckTracker.js';
@@ -102,7 +102,7 @@ export class ServerService {
      */
     async getServerSchema(categoryName, serverName) {
         try {
-            const provider = await getServerSchemaProvider();
+            const provider = ServerSchemaProvider.getInstance();
             const serverMcpConfig = await mcpManager.getServerMcpConfig(categoryName, serverName);
             return await provider.getSchema(categoryName, serverMcpConfig?.schemas || `${serverName}.json`);
         }

package/dist/utils/logger.d.ts

@@ -9,6 +9,8 @@ export declare class Logger {
     private static getTimestamp;
     private static writeToLogFile;
     static log(message: string): Promise<void>;
+    static info(message: string): Promise<void>;
+    static warn(message: string): Promise<void>;
     static debug(message: string | object): Promise<void>;
     static error(message: string, error?: unknown): Promise<void>;
 }

package/dist/utils/logger.js

@@ -48,6 +48,16 @@ export class Logger {
         console.log(message);
         await this.writeToLogFile('INFO', message);
     }
+    static async info(message) {
+        console.info(message);
+        await this.writeToLogFile('INFO', message);
+    }
+    static async warn(message) {
+        const yellowColor = '\x1b[33m';
+        const resetColor = '\x1b[0m';
+        console.warn(`${yellowColor}${message}${resetColor}`);
+        await this.writeToLogFile('WARN', message);
+    }
     static async debug(message) {
         let formattedMessage;
         if (typeof message === 'object') {

package/dist/web/public/js/modal/installation.js

@@ -175,7 +175,7 @@ async function pollInstallStatus(categoryName, serverName, targets, interval = 2
                             delayedAppendInstallLoadingMessage(`${target}: ${msg}`);
                             lastMessages[target] = msg;
                         }
-                        if (status !== "completed") {
+                        if (status !== "completed" && status !== "failed") {
                             allTargetsCompleted = false;
                         }
                     }

package/dist/web/public/js/onboard/ONBOARDING_PAGE_DESIGN.md

@@ -168,9 +168,9 @@ A toggle switch allows users to switch between the standard form view and a raw
   - Calls `getFormData()` (from `formProcessor.js`) to get the current form data as `FeedConfiguration`.
   - Sends an initial POST request to `/api/categories/onboard` with the `FeedConfiguration` object and an `isUpdate` flag.
   - The "Publish" button shows a spinning loader icon and its text changes to "Publishing...". Both "Validate" and "Publish" buttons are disabled.
-  - **Polling for Status**: If the initial publish request is successful and the operation is not immediately completed or failed, `handlePublish` initiates polling using the shared `pollOperationStatus` function (from `validationHandlers.js`). This function periodically calls `GET /api/categories/:categoryName/onboard/status`.
-  - **Displaying Results**: The shared `updateOperationDisplay` function (from `validationHandlers.js`) formats and displays the results from both the initial publish call and subsequent status polls in the relevant status panel. It shows overall status, messages, PR info (if available), and detailed validation results if included in the publish response.
-  - **Completion/Failure**: Polling stops when the status is 'COMPLETED', 'FAILED', or 'succeeded'. Upon completion or failure, the "Publish" button reverts to its original state, and both "Validate" and "Publish" buttons are re-enabled. Success and error messages are displayed using `showToast()`.
+  - **Polling for Status**: If the initial publish request is successful and the operation is not immediately completed or failed, `handlePublish` initiates polling. The shared `pollOperationStatus` function (from `validationHandlers.js`) is called, which periodically queries `GET /api/categories/:categoryName/onboard/status?operationType=FULL_ONBOARDING`. `pollOperationStatus` now returns a boolean to manage polling continuation.
+  - **Displaying Results**: The shared `updateOperationDisplay` function (from `validationHandlers.js`) formats and displays detailed progress, including individual steps, from both the initial publish call and subsequent status polls.
+  - **Completion/Failure**: Polling stops based on the status returned by `pollOperationStatus`. Upon completion or failure, buttons are reset, and `showToast()` displays messages. For detailed information on recent changes to polling and status display, see Section 9: "Enhanced Operation Status Polling and Display".
 - **Validation (`handleValidation` in `validationHandlers.js`)**:
 - **Validation (`handleValidation` in `validationHandlers.js`)**:
   - The `validationStatusPanel` (unique per tab) is located under the "MCP Servers" section (or equivalent) and above the main action buttons ("Validate", "Publish"). It is a foldable panel.
@@ -179,14 +179,14 @@ A toggle switch allows users to switch between the standard form view and a raw
     - Sends an initial POST request to `/api/categories/onboard/validate`.
     - The "Validate" button shows a spinning loader icon and its text changes to "Validating...". Both "Validate" and "Publish" buttons are disabled.
   - **Polling for Status**:
-    - If the initial validation request is successful and the operation is not immediately completed or failed, `handleValidation` initiates polling using the shared `pollOperationStatus` function (from `validationHandlers.js`).
-    - This function uses the `onboardingId` (category name) from the validation response to periodically call `GET /api/categories/:categoryName/onboard/status`.
+    - If the initial validation request is successful and the operation is not immediately completed or failed, `handleValidation` initiates polling.
+    - The shared `pollOperationStatus` function (from `validationHandlers.js`) is called, which periodically queries `GET /api/categories/:categoryName/onboard/status?operationType=VALIDATION_ONLY` (using the category name from the form). `pollOperationStatus` now returns a boolean to manage polling continuation.
   - **Displaying Results**:
-    - The shared `updateOperationDisplay` function (from `validationHandlers.js`) formats and displays the results from both the initial validation call and subsequent status polls in the relevant status panel.
-    - It handles different structures of the `validationStatus` object in the response, including displaying overall status, messages, and detailed results for each server if `validationStatus.serverResults` is present.
+    - The shared `updateOperationDisplay` function (from `validationHandlers.js`) formats and displays detailed progress, including individual steps, from both the initial validation call and subsequent status polls.
+    - It handles different structures of the `validationStatus` object and overall operation status.
   - **Completion/Failure**:
-    - Polling stops when the status is 'COMPLETED', 'FAILED', or 'succeeded'.
-    - Upon completion or failure, the "Validate" button reverts to its original state ("Validate" text and icon), and both "Validate" and "Publish" buttons are re-enabled.
+    - Polling stops based on the status returned by `pollOperationStatus`.
+    - Upon completion or failure, buttons are reset. For detailed information on recent changes to polling and status display, see Section 9: "Enhanced Operation Status Polling and Display".
 - **Copy JSON (`copyJsonToClipboard` in `uiHandlers.js`)**: Copies the content of `jsonEditorTextarea` to the clipboard. Uses `showToast()` for feedback.
 - **Global Function Exposure**: Necessary UI handler functions (like `addServer`, `removeServer`, `toggleSectionContent`, etc.) are attached to the `window` object so they can be called from `onclick` attributes in the HTML templates.
 - **Custom Notifications**: Standard browser `alert()` calls have been replaced with a custom toast notification system (`showToast()` from `../notifications.js`). This system requires an `.alert-container` div in the host HTML (`onboard.html`) and uses CSS from `css/notifications.css` for styling. The `notifications.js` module handles the creation, display, and dismissal (manual and automatic) of these toasts without relying on Bootstrap's JavaScript.
@@ -290,6 +290,38 @@ This section documents significant fixes and behavior changes implemented recent
         - **Outcome:** The "Publish" and "Validate" buttons now reliably revert to their default active states when an operation (validation or publish) concludes with a failure, regardless of the casing of the status string from the backend or whether the failure occurs immediately or during polling.
   - **Overall Outcome:** These changes improve the reliability of data submission and provide more accurate UI feedback for asynchronous operations on the "Create Server in Existing Category" tab.
 
+- **Enhanced Operation Status Polling and Display (May 2025 - Current Session):**
+  - **Context:** Significant improvements were made to the handling of asynchronous operations (validation and publishing), including more detailed progress display, robust polling, and clearer API interactions.
+  - **Issues Addressed & Solutions:**
+    1.  **Server-Side API (`server.ts` - `/api/categories/:categoryName/onboard/status`):**
+        -   The endpoint now requires an `operationType` query parameter (e.g., `VALIDATION_ONLY`, `FULL_ONBOARDING`).
+        -   The response payload (`OperationStatus`) was enhanced to include:
+            -   `steps`: An array of objects detailing each step of the operation (name, serverName, timestamp, status, errorMessage).
+            -   `operationType`: Reflects the type of operation being tracked, taken from the status object.
+            -   `feedConfiguration`: Conditionally included for successful `VALIDATION_ONLY` operations if present in the result.
+            -   The `onboardingId` in the response is `categoryName_operationType`.
+            -   The `message` field in the response now prioritizes the last step's name or an overall error message.
+    2.  **Client-Side Polling Logic (`validationHandlers.js` - `pollOperationStatus`):**
+        -   The function now accepts an `operationType` parameter, which is passed to the API.
+        -   It returns a boolean promise (`Promise<boolean>`) indicating whether polling should continue, allowing the caller (`handleValidation` or `handlePublish`) to manage `clearInterval`.
+        -   Calls `ensureProgressToggleListener` to ensure the UI for displaying progress steps is interactive.
+        -   Status comparisons (`COMPLETED`, `FAILED`, `SUCCEEDED`) are now case-insensitive.
+    3.  **Operation Initiation (`publishHandler.js` - `handlePublish`, `validationHandlers.js` - `handleValidation`):**
+        -   When initiating polling, these functions now pass the correct `operationType` (`FULL_ONBOARDING` for publish, `VALIDATION_ONLY` for validate) and use the original `finalFeedConfiguration.name` as the `categoryName` for the polling request.
+        -   They now manage `clearInterval` based on the boolean returned by `pollOperationStatus`.
+        -   Both handlers call `ensureProgressToggleListener` at the beginning to prepare the UI for status updates.
+        -   `handlePublish` includes improved error handling for the initial publish request, ensuring UI elements are correctly updated even if the initial call fails or returns a terminal status.
+    4.  **UI Display (`validationHandlers.js` - `updateOperationDisplay`):**
+        -   A new collapsible "Progress" section is displayed, showing detailed `steps` from the API response. Each step includes:
+            -   A status icon (error, in-progress spinner, success).
+            -   The step name, server name (if applicable), and timestamp.
+            -   An error message for the step, if any.
+        -   The visibility of the "Progress" section is managed by `ensureProgressToggleListener` (which attaches a click handler to the section header) and the `toggleSectionContent` utility.
+        -   The `operationType` is now displayed.
+        -   The logic for displaying the overall status spinner has been updated to cover more in-progress states (e.g., `PENDING`, `VALIDATING`, `PRCREATING`, `PUBLISHING`) and uses case-insensitive comparisons.
+    5.  **Progress Section Toggling (`validationHandlers.js` - `ensureProgressToggleListener`):**
+        -   A new exported utility function, `ensureProgressToggleListener`, was added. It attaches a click event listener to the status content element. This listener delegates to `toggleSectionContent` (from `uiHandlers.js`) when the progress section header is clicked, allowing users to expand or collapse the detailed list of progress steps. The listener is attached only once per status content element.
+  - **Outcome:** These changes provide users with more granular and interactive feedback on long-running operations, improve the robustness and accuracy of status polling, and align client-server communication for tracking asynchronous onboarding tasks.
 ---
 
 ## 10. Server Validation System