components/log-viewer-webui/client/src/App.tsx (6)

3-5: Consider cleaning up commented code

Rather than commenting out old code, consider removing it completely if it's no longer needed, or add a TODO comment explaining why it's temporarily commented out.

---

12-12: Remove commented code

This commented code line for an unused collection should be removed.

---

20-28: Query implementation looks good but consider extracting to a separate function

The MongoDB reactive query is properly implemented with the useTracker hook. However, consider extracting the query to a separate function for better readability and testability.

---

40-46: Remove commented debug code

Remove the commented debug logging code before submitting the final PR.

---

63-65: Clean up commented components

Remove these commented components if they are no longer needed.

---

48-62: Consider using proper semantic HTML and styling

The current implementation simply displays JSON strings in divs. Consider using proper semantic HTML elements and adding some basic styling for better readability.

-        <div>
-            {results.map((r) => (
-                <div>
-                    {JSON.stringify(r)}
-                </div>
-            ))}
-            {results2.map((r) => (
-                <div>
-                    {JSON.stringify(r)}
-                </div>
-            ))}
-
-        </div>
+        <div className="results-container">
+            <section className="results-section">
+                <h2>Query 1 Results (IDs 1-10)</h2>
+                <ul>
+                    {results.map((r) => (
+                        <li key={r._id}>
+                            <pre>{JSON.stringify(r, null, 2)}</pre>
+                        </li>
+                    ))}
+                </ul>
+            </section>
+            <section className="results-section">
+                <h2>Query 2 Results (IDs 1-5)</h2>
+                <ul>
+                    {results2.map((r) => (
+                        <li key={r._id}>
+                            <pre>{JSON.stringify(r, null, 2)}</pre>
+                        </li>
+                    ))}
+                </ul>
+            </section>
+        </div>

🧰 Tools

🪛 Biome (1.9.4)

[error] 51-51: Missing key property for this element in iterable.

The order of the items may change, and having a key can help React identify which item was moved.
Check the React documentation.

(lint/correctness/useJsxKeyInIterable)

---

[error] 56-56: Missing key property for this element in iterable.

The order of the items may change, and having a key can help React identify which item was moved.
Check the React documentation.

(lint/correctness/useJsxKeyInIterable)

components/log-viewer-webui/client/src/mongoCDCLib/useTracker.tsx (2)

12-12: Fix the documentation reference to match the parameter type.

The JSDoc references MongoReplicaCollectionReactiveCursor but the parameter type is MongoCollectionReactiveCursor.

-* @param getCursor Function that returns a MongoReplicaCollectionReactiveCursor.
+* @param getCursor Function that returns a MongoCollectionReactiveCursor.

---

31-33: Consider implementing better error handling.

The current implementation only logs errors to the console without any recovery mechanism or user notification.

onError: (error: unknown) => {
    console.error("Error fetching data:", error);
+   // Consider adding a more robust error handling strategy here:
+   // - Set an error state that can be returned from the hook
+   // - Implement a retry mechanism 
+   // - Notify the user through a toast/notification system
},

components/log-viewer-webui/client/src/mongoCDCLib/MongoCollection.ts (1)

57-58: Implement non-reactive cursors as noted in TODO.

There's a TODO comment about adding support for non-reactive cursors that should be implemented.

Would you like me to provide an implementation for non-reactive cursors? This would allow for better optimization when real-time updates aren't needed.

components/log-viewer-webui/client/src/mongoCDCLib/MongoCollectionCursor.ts (1)

92-97: Improve error handling and type checking in callback.

The code could use better type checking for the response object.

- }, (response: {error?: Error; data?: Document[]}) => {
-     if (response.error) {
-         reject(response.error);
+ }, (response: unknown) => {
+     if (!response || typeof response !== 'object') {
+         reject(new Error('Invalid response from server'));
+         return;
+     }
+     
+     const typedResponse = response as {error?: Error; data?: Document[]};
+     if (typedResponse.error) {
+         reject(typedResponse.error);

components/log-viewer-webui/server/src/plugins/MongoSocketIoServer/utils.ts (1)

26-30: Use Object.prototype.hasOwnProperty.call instead of Object.hasOwn.

Per the coding guidelines for **/*.{cpp,hpp,java,js,jsx,tpp,ts,tsx} preferred format would be false == <expression> rather than !<expression>. Similarly, for consistency and broader compatibility, use Object.prototype.hasOwnProperty.call instead of Object.hasOwn.

for (const key in query) {
-   if (Object.hasOwn(query, key)) {
+   if (false === Object.prototype.hasOwnProperty.call(query, key)) {
+       continue;
+   }
+   
    changeStreamQuery[`fullDocument.${key}`] = query[key] as unknown;
}

components/log-viewer-webui/client/src/mongoCDCLib/MongoCollectionReactiveCursor.ts (1)

88-92: Type-guard can be simplified & made safer

if ("undefined" !== typeof response.data.queryId) will throw when response.data is undefined.
Use optional chaining:

- if ("undefined" !== typeof response.data.queryId) {
+ if (response.data?.queryId !== undefined) {

components/log-viewer-webui/server/src/plugins/MongoSocketIoServer/MongoWatcherCollection.ts (1)

195-205: Lack of error propagation on fetch failures

When collection.find() fails, the error is logged but clients are never informed, leaving them silently stale.

Emit an error event so subscribers can react:

catch (error) {
    console.error("Error fetching data for update:", error);
    this.io.to(`${queryId}`).emit("collection::find::update", {
        queryId,
        error: (error as Error).message,
        data: [],
    });
}

components/log-viewer-webui/server/src/plugins/MongoSocketIoServer/index.ts (1)

233-237: Conform to project boolean-comparison guideline

Coding-guideline: prefer false == <expr> rather than !<expr>.
Replace the negated truthy check:

-        if (!collectionName) {
+        if (false == collectionName) {
             this.#fastify.log.error("Collection name is undefined");
             return;
         }

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

components/log-viewer-webui/server/src/plugins/MongoSocketIoServer/index.ts (3)

47-48: ⚠️ Potential issue

Add the missing third generic placeholder (ServerSideEvents) to the Server type

The socket.io Server constructor expects four generic parameters in the order
<ListenEvents, EmitEvents, ServerSideEvents, SocketData>.
By supplying only three, SocketData is currently interpreted as ServerSideEvents, so socket.data is typed as any, defeating the type-safety you were aiming for.

-    #io: Server<ClientToServerEvents, ServerToClientEvents, SocketData>;
+    #io: Server<ClientToServerEvents, ServerToClientEvents, Record<string, never>, SocketData>;
…
-        this.#io = new Server<
-            ClientToServerEvents,
-            ServerToClientEvents,
-            SocketData
-        >(fastify.server);
+        this.#io = new Server<
+            ClientToServerEvents,
+            ServerToClientEvents,
+            Record<string, never>,
+            SocketData
+        >(fastify.server);

Also applies to: 70-74

---

150-171: ⚠️ Potential issue

Ack the client’s collection::init call on success

The client provides a callback but it is invoked only on error.
Without an acknowledgement, the caller hangs indefinitely, assuming the request is still pending.

         (socket.data as SocketData).collectionName = collectionName;
+
+        // Successful initialisation → notify client
+        callback({});

---

271-299: 🛠️ Refactor suggestion

Remove queryId from #subscribedQueryIdsMap after a successful unsubscribe

#unsubscribe cleans up watchers but leaves stale entries in #subscribedQueryIdsMap.
Subsequent disconnects produce spurious error logs and attempt double-unsubscription.

         this.#subscribeToQueryId(queryId, socket.id);
@@
-        const lastSubscriber = collection.unsubcribeFromWatcher(queryId, socket.id);
+        const lastSubscriber = collection.unsubcribeFromWatcher(queryId, socket.id);
+
+        // House-keeping: drop the queryId for this connection
+        const ids = this.#subscribedQueryIdsMap.get(socket.id);
+        if ("undefined" !== typeof ids) {
+            const idx = ids.indexOf(queryId);
+            if (-1 !== idx) {
+                ids.splice(idx, 1);
+                if (0 === ids.length) {
+                    this.#subscribedQueryIdsMap.delete(socket.id);
+                }
+            }
+        }

components/log-viewer-webui/server/src/plugins/MongoSocketIoServer/index.ts (1)

236-240: Follow project style-guide: avoid the ! shorthand

Guidelines specify false == <expression> over !<expression>.
Use an explicit comparison to keep style consistent and avoid accidental truthiness checks on empty strings.

-if (!collectionName) {
+if (false == collectionName) {

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

components/log-viewer-webui/server/src/plugins/MongoSocketIoServer/typings.ts (8)

13-16: Consider renaming Err interface for clarity

The interface name Err is somewhat ambiguous. A more descriptive name like ErrorResponse would better convey its purpose and improve code readability.

-interface Err {
+interface ErrorResponse {
    error: string;
    queryId?: number;
}

Also update the Response type accordingly:

-type Response<T> = Err | Success<T>;
+type Response<T> = ErrorResponse | Success<T>;

---

46-46: Nested data structure seems redundant

The callback response type Response<{data: Document[]}> contains nested data structures - Success<T> already includes a data property. Consider simplifying to Response<Document[]> for a cleaner design.

-        callback: (res: Response<{data: Document[]}>) => void) => void;
+        callback: (res: Response<Document[]>) => void) => void;

---

80-81: Empty interface can be replaced with a type alias

Following TypeScript best practices, empty interfaces should be replaced with type aliases using Record.

-interface InterServerEvents {
-}
+type InterServerEvents = Record<string, never>;

🧰 Tools

🪛 Biome (1.9.4)

[error] 79-81: An empty interface is equivalent to {}.

Safe fix: Use a type alias instead.

(lint/suspicious/noEmptyInterface)

---

100-100: Fix typo in comment

There's a typo in the comment: "repsent" should be "represent".

-/**
- * Unique ID to repsent each socket connection.
- */
+/**
+ * Unique ID to represent each socket connection.
+ */

---

46-46: Inconsistent Promise handling for socket.io callbacks

The event handlers with callbacks don't return Promises, except for "collection::find::unsubscribe". Consider standardizing the Promise handling across all event handlers for consistency.

Either make all event handlers return a Promise:

-    "collection::find::toArray": (
-        requestArgs: {
-            query: Filter<Document>;
-            options: FindOptions;
-        },
-        callback: (res: Response<{data: Document[]}>) => void) => void;
+    "collection::find::toArray": (
+        requestArgs: {
+            query: Filter<Document>;
+            options: FindOptions;
+        },
+        callback: (res: Response<{data: Document[]}>) => void) => Promise<void>;

Or remove the Promise return from "collection::find::unsubscribe":

-    "collection::find::unsubscribe": (
-        requestArgs: {
-            queryId: number;
-        }
-    ) => Promise<void>;
+    "collection::find::unsubscribe": (
+        requestArgs: {
+            queryId: number;
+        }
+    ) => void;

Also applies to: 52-52

---

33-58: Consider adding JSDoc comments to individual event handlers

While the ClientToServerEvents type has a general comment, each event handler would benefit from individual JSDoc comments explaining their specific purpose and behavior.

For example:

type ClientToServerEvents = {
    /**
     * Emitted when client disconnects from the server
     */
    "disconnect": () => void;
    
    /**
     * Initializes a collection for the client
     * @param requestArgs - Contains the collection name to initialize
     * @param callback - Called with success or error response
     */
    "collection::init": (
        requestArgs: {
            collectionName: string;
        },
        callback: (res: Response<void>) => void
    ) => void;
    
    // ... Add similar comments for other event handlers
};

---

33-58: Socket event naming could be more REST-like

The current event naming uses "::" separators. Consider using a more standard REST-like naming convention with "/" separators for better readability and consistency with common API patterns.

For example:

type ClientToServerEvents = {
-    "disconnect": () => void;
-    "collection::init": (
+    "disconnect": () => void;
+    "collection/init": (
        // ...
    ) => void;
-    "collection::find::toArray": (
+    "collection/find/toArray": (
        // ...
    ) => void;
    // ... update other event names similarly
};

interface ServerToClientEvents {
-    "collection::find::update": (respArgs: {
+    "collection/find/update": (respArgs: {
        // ...
    }) => void;
}

Also applies to: 63-68

---

127-127: Consider making the timeout configurable

CLIENT_UPDATE_TIMEOUT_MS is defined as a hardcoded constant. Consider allowing this value to be configurable, either through environment variables or constructor parameters in the main implementation class.

-const CLIENT_UPDATE_TIMEOUT_MS = 500;
+const DEFAULT_CLIENT_UPDATE_TIMEOUT_MS = 500;
+const CLIENT_UPDATE_TIMEOUT_MS = process.env.CLIENT_UPDATE_TIMEOUT_MS 
+    ? parseInt(process.env.CLIENT_UPDATE_TIMEOUT_MS, 10) 
+    : DEFAULT_CLIENT_UPDATE_TIMEOUT_MS;

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

components/log-viewer-webui/client/src/App.tsx (2)

25-27: ⚠️ Potential issue

Using index as key in iterable

Using array index as key for iterated elements is not recommended, as it can lead to rendering issues when the array order changes. Consider using a unique identifier from the data instead.

{singleResult.map((r, index) => (
-    <div key={index}>{JSON.stringify(r)}</div>
+    <div key={r._id || index}>{JSON.stringify(r)}</div>
))}

---

45-47: ⚠️ Potential issue

Using index as key in iterable

Using array index as key for iterated elements is not recommended, as it can lead to rendering issues when the array order changes. Consider using a unique identifier from the data instead.

{singleResult.map((r, index) => (
-    <div key={index}>{JSON.stringify(r)}</div>
+    <div key={r._id || index}>{JSON.stringify(r)}</div>
))}

components/log-viewer-webui/client/package.json (1)

30-34: Redundant & incompatible @types/socket.io-client entry – echoing earlier feedback

socket.io-client@4.x ships its own typings; @types/socket.io-client@3 targets the v3 API and will clash with the bundled d.ts files.
Please drop the dev-dependency to prevent duplicate symbol errors.

This was already pointed out in a previous review.

components/log-viewer-webui/server/src/plugins/MongoSocketIoServer/index.ts (1)

154-175: ⚠️ Potential issue

collection::init never ACKs success – client callbacks hang indefinitely

After validating and storing collectionName, the server should invoke the provided callback to acknowledge success.

         socket.data.collectionName = collectionName;
+
+        // Notify caller that initialisation succeeded
+        callback({});

Without this, the caller’s Promise will never resolve.

Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro