From f403a3dd5922a9f6d9dbeb02a9ce249366bb2bdd Mon Sep 17 00:00:00 2001 From: Scott Idem Date: Mon, 15 Dec 2025 19:07:06 -0500 Subject: [PATCH] Saving the final changes for the night. --- GEMINI.md | 30 ++++++++++++++++++++++++++---- src/lib/ae_api/api_post_object.ts | 6 ++++++ 2 files changed, 32 insertions(+), 4 deletions(-) diff --git a/GEMINI.md b/GEMINI.md index 1cb3f005..50a105df 100644 --- a/GEMINI.md +++ b/GEMINI.md @@ -107,9 +107,7 @@ This pattern isolates API logic from data shaping logic, making the code more mo For the IDAA client, create an administrative dashboard ("god mode") to monitor live Jitsi meetings—including meeting duration, participant lists, and moderator roles—without needing to join the meetings directly. This is primarily for ensuring meetings are running correctly and for data collection. ### Architectural Decision -A purely client-side approach using the Jitsi External API is not feasible, as it requires being a participant in the meeting. A server-side solution is necessary. - -After considering a log-parsing approach, the following hybrid architecture was chosen as the most robust and scalable solution. +A purely client-side approach using the Jitsi External API is not feasible, as it requires being a participant in the meeting. A server-side solution is necessary. After considering a log-parsing approach, the following hybrid architecture was chosen as the most robust and scalable solution. 1. **Server-Side XMPP Bot (Stats Collector):** * A new, lightweight backend service will be created (likely in Python or Node.js). @@ -130,4 +128,28 @@ After considering a log-parsing approach, the following hybrid architecture was * This page will periodically fetch data from the new API endpoint to display a live overview of all ongoing meetings. ### Rationale -This approach was chosen over log-parsing because the XMPP protocol is a stable, official API for Jitsi, making the solution less likely to break on future Jitsi updates. It provides true real-time data for the live dashboard while simultaneously creating a valuable, structured dataset for historical reporting. \ No newline at end of file +This approach was chosen over log-parsing because the XMPP protocol is a stable, official API for Jitsi, making the solution less likely to break on future Jitsi updates. It provides true real-time data for the live dashboard while simultaneously creating a valuable, structured dataset for historical reporting. + +--- +## Jitsi Stats Reporting Debugging (End of Day 2025-12-15) + +### Objective +As a pragmatic first step towards the "God Mode" view, implement a "moderator-pushed" stats reporting system. A moderator's browser will periodically send the meeting stats to an existing Aether activity log endpoint. + +### Progress +1. **Client-Side Logic:** The Svelte component now collects live meeting stats (duration, participants, roles) via the Jitsi External API. +2. **Reporting Function:** A `report_meeting_stats` function has been created to bundle this data and call the `create_ae_obj__activity_log` API function. +3. **Trigger:** A 30-second timer (`setInterval`) is implemented to call the reporting function automatically for users where `is_moderator` is true. + +### Current Problem +The feature is not working. The browser's console logs show that the `report_meeting_stats` function is being called and the data payload is being correctly prepared. However, the API call fails silently: +* No success or error messages are logged in the console from the `try...catch` block around the API call. +* The API call never reaches the FastAPI server (no entry in the server's access logs). + +### Investigation & Last Actions +* My initial hypothesis was a hanging network request due to a missing timeout. +* **Action Taken:** I modified the underlying `post_object` function in `src/lib/ae_api/api_post_object.ts` to add a 20-second timeout to the `fetch` call. +* **Result:** This had no effect. The request still disappears without triggering the success, error, or timeout conditions. This suggests the issue is preventing the `fetch` call from executing correctly at a fundamental level. + +### Next Step +The crucial next step is to use the **Network** tab in the browser's developer tools. We need to observe what happens, if anything, at the exact moment the "Stats payload being sent" message appears in the console. This will tell us if a request is being blocked by the browser itself (e.g., CORS pre-flight failure) or if it's failing to even be dispatched. diff --git a/src/lib/ae_api/api_post_object.ts b/src/lib/ae_api/api_post_object.ts index 900c4a4a..bb34835c 100644 --- a/src/lib/ae_api/api_post_object.ts +++ b/src/lib/ae_api/api_post_object.ts @@ -96,6 +96,11 @@ export const post_object = async function post_object({ for (let attempt = 1; attempt <= retry_count; attempt++) { try { const controller = new AbortController(); + const timeoutId = setTimeout(() => { + console.error('API POST request timed out.'); + controller.abort(); + }, 20000); // 20-second timeout + const fetchOptions: RequestInit = { method: 'POST', headers: headers_cleaned, @@ -108,6 +113,7 @@ export const post_object = async function post_object({ } const response = await fetch(url.toString(), fetchOptions); + clearTimeout(timeoutId); // Clear the timeout if the request completes in time if (log_lvl) { console.log(`Response: status=${response.status} attempt=${attempt}`);