feat(mcp): add live MCP tool progress bar for long running MCP tool calls (Issue #16934) by jasmeetsb · Pull Request #18604 · google-gemini/gemini-cli

jasmeetsb · 2026-02-09T06:44:39Z

Display real-time progress bars for MCP tool operations by wiring SDK onprogress callbacks through core events to the CLI UI layer.

Closes Feature Request #16934

Summary

Adds MCP progress report support per the MCP specification (notifications/progress). MCP servers can now emit progress updates during tool execution, which are displayed as a live progress bar in the terminal. Supports both determinate (percentage with known total) and indeterminate (step count) progress modes.

Screenshot

Details

Core layer (packages/core):

mcp-client.ts: Generates a progressToken per tool call and passes an onprogress callback to the MCP SDK's callTool. Progress notifications are forwarded via coreEvents.emitMCPToolProgress()
mcp-tool.ts: Accepts progress callback from the client layer, wires it to the invocation's execute() method, and emits typed MCPToolProgress events with call correlation
tool-executor.ts: Assigns a callId to MCP tool invocations before execution so progress events can be correlated to specific tool calls
events.ts: New MCPToolProgress event type and emitMCPToolProgress helper

CLI layer (packages/cli):

useMCPProgress.ts: Hook that subscribes to MCPToolProgress core events and maintains a Map<callId, progress> state
useToolExecutionScheduler.ts: Integrates progress state, passes callId mappings and clearProgress callback to tool message components
ToolShared.tsx: Renders a block-character progress bar with percentage and message below the tool spinner
ToolMessage.tsx: Passes progress data through to ToolShared

15 files changed, 803 insertions(+), 8 deletions(-).

Related Issues

Closes Feature Request #16934

How to Validate

All existing tests pass (npm test — 622 test files, 9750 tests, 0 failures across core, cli, and vscode packages). 17 new tests were added covering the progress functionality.

Run the unit tests covering the new functionality:

npx vitest run packages/core/src/tools/mcp-tool.test.ts packages/core/src/tools/mcp-client.test.ts packages/core/src/scheduler/tool-executor.test.ts packages/cli/src/ui/hooks/useMCPProgress.test.ts

For manual validation, configure any MCP server that emits notifications/progress (e.g. (https://mcpservers.org/servers/dazeb/mcp-everything)) and invoke one of its tools:
- Percentage progress: Tool with a known total shows a progress bar updating 0%→100%
- Indeterminate progress: Tool with no total shows a raw step count
- Error during progress: Tool that fails mid-progress cleans up the progress bar
- No progress (regression): Tools without progress support work normally with just a spinner

Pre-Merge Checklist

gemini-code-assist · 2026-02-09T06:45:06Z

Summary of Changes

Hello @jasmeetsb, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the user experience by integrating real-time progress indicators for MCP tool executions within the CLI. By establishing a robust event-driven mechanism from the MCP SDK to the UI, users can now observe the live status of operations, whether they are percentage-based or step-based. This change improves transparency and responsiveness for long-running tasks without altering existing user-facing APIs.

Highlights

Real-time MCP Tool Progress Bars: Introduces live progress bars in the CLI for long-running Model Context Protocol (MCP) tool operations, providing immediate visual feedback to the user.
Event-driven Progress Reporting: Implements an event-driven architecture where MCP SDK onprogress callbacks are wired through core events (CoreEvent.MCPToolProgress) to the CLI UI layer, ensuring real-time updates.
Support for Determinate and Indeterminate Progress: The progress bar dynamically adapts to display either a percentage (when a total is known) or a raw step count (for indeterminate progress), enhancing flexibility for various tool types.
Dedicated UI Hook for Progress Management: Adds a new useMCPProgress React hook in the CLI to subscribe to and manage the state of MCP tool progress events, ensuring proper state handling and cleanup.
Correlation of Progress Events to Tool Calls: A callId is now assigned to MCP tool invocations in the tool-executor to uniquely identify and correlate progress updates with specific tool executions.

Changelog

packages/cli/src/ui/components/messages/ToolMessage.tsx
- Imports MCPProgressIndicator and ToolCallStatus.
- Adds mcpProgress as a new prop to ToolMessageProps.
- Conditionally renders the MCPProgressIndicator component when a tool is in the 'executing' status and mcpProgress data is available.
packages/cli/src/ui/components/messages/ToolShared.tsx
- Introduces the MCPProgressIndicatorProps interface.
- Adds the MCPProgressIndicator React component, responsible for rendering a block-character progress bar.
- The MCPProgressIndicator displays a percentage if total is provided, otherwise it shows the raw progress value.
- Includes logic to clamp progress values to prevent rendering issues with String.repeat() for misbehaving MCP servers.
packages/cli/src/ui/hooks/toolMapping.ts
- Imports the Progress type from @modelcontextprotocol/sdk/types.js.
- Adds an optional mcpProgress property of type Progress to the IndividualToolCallDisplay interface.
- Modifies mapToDisplay to extract and assign mcpProgress from executing tool calls to the display object.
packages/cli/src/ui/hooks/useMCPProgress.test.ts
- New file containing unit tests for the useMCPProgress hook.
- Tests cover initialization, updating state on progress events, tracking multiple concurrent calls, updating existing progress, clearing specific progress, clearing all progress, rejecting late events, and event unsubscription.
packages/cli/src/ui/hooks/useMCPProgress.ts
- New React hook useMCPProgress for managing MCP tool progress state.
- Subscribes to CoreEvent.MCPToolProgress events emitted from the core layer.
- Maintains a progressState map, storing progress data keyed by callId.
- Includes clearProgress(callId) to remove progress for a specific tool call and clearAllProgress() to reset all progress.
- Uses a completedCallIds ref to prevent stale progress events from re-introducing completed calls into the state.
packages/cli/src/ui/hooks/useToolExecutionScheduler.ts
- Imports the new useMCPProgress hook.
- Integrates progressState, clearProgress, and clearAllProgress from useMCPProgress.
- Calls clearAllProgress() at the start of a new tool schedule to reset the progress state.
- Uses useMemo to derive toolCallsWithProgress, merging mcpProgress data into TrackedToolCall objects for currently executing tools.
- Adds a useEffect to call clearProgress for any tool call that transitions to a terminal state ('success', 'cancelled', 'error').
- Updates the return value to provide toolCallsWithProgress instead of the raw toolCalls.
packages/cli/src/ui/types.ts
- Imports the Progress type from @modelcontextprotocol/sdk/types.js.
- Adds an optional mcpProgress property to the IndividualToolCallDisplay interface to hold progress data.
packages/core/src/scheduler/tool-executor.test.ts
- Adds new test cases for ToolExecutor related to setCallId for MCP progress.
- Verifies that setCallId is invoked on an MCP tool invocation if the method exists.
- Ensures that the executor does not fail if an invocation object lacks a setCallId method.
packages/core/src/scheduler/tool-executor.ts
- Modifies the execute method to check if the invocation object has a setCallId method.
- If setCallId exists, it is called with the current callId to enable progress tracking within the MCP tool invocation.
packages/core/src/scheduler/types.ts
- Imports the Progress type from @modelcontextprotocol/sdk/types.js.
- Adds an optional mcpProgress property to the ExecutingToolCall type to store current progress information.
packages/core/src/tools/mcp-client.test.ts
- Updates the mock for coreEvents to include emitMCPToolProgress.
- Adds integration tests for McpCallableTool to confirm that the onprogress callback is correctly passed to the SDK's callTool method when a callId is present.
- Verifies that onprogress is not passed when callId is not set.
packages/core/src/tools/mcp-client.ts
- Imports the Progress type from @modelcontextprotocol/sdk/types.js.
- Defines a new interface CallableToolWithProgress that extends CallableTool and includes an optional progressCallback in its callTool method signature.
- Updates McpCallableTool to implement CallableToolWithProgress.
- Modifies McpCallableTool.callTool to accept an optional progressCallback and passes it, along with resetTimeoutOnProgress: true, to the underlying SDK client's callTool options.
packages/core/src/tools/mcp-tool.test.ts
- Updates imports to include DiscoveredMCPToolInvocation and coreEvents.
- Adds new test suite for DiscoveredMCPToolInvocation progress.
- Tests confirm that progressCallback is passed to the underlying CallableTool.callTool when callId is set.
- Verifies that CoreEvent.MCPToolProgress events are correctly emitted via coreEvents with the appropriate payload when progress updates are received.
- Ensures no progress events are emitted if callId is not set.
packages/core/src/tools/mcp-tool.ts
- Imports Progress, coreEvents, and CallableToolWithProgress.
- Adds a private _callId property and public setCallId method to DiscoveredMCPToolInvocation.
- Within DiscoveredMCPToolInvocation.execute, a progressCallback function is created if _callId is set.
- This progressCallback emits CoreEvent.MCPToolProgress events with the callId, serverName, toolName, and progress details.
- The mcpTool.callTool method is now conditionally invoked, passing the progressCallback if it exists, ensuring progress updates are handled.
packages/core/src/utils/events.ts
- Imports debugLogger.
- Defines the MCPToolProgressPayload interface to standardize progress event data.
- Adds MCPToolProgress as a new enum member to CoreEvent.
- Extends the CoreEvents interface to include MCPToolProgress with its payload.
- Adds emitMCPToolProgress method to CoreEventEmitter for direct (non-queued) emission of progress events, including a check for negative progress values.

Activity

The author has added 17 new tests specifically covering the new progress functionality.
The pull request has been validated on MacOS (npm run) and Linux (npm run).

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

jasmeetsb · 2026-02-09T06:50:12Z

/gemini review

gemini-code-assist

Code Review

This pull request introduces a real-time progress bar for long-running MCP tool calls, which is a great enhancement for user experience. The implementation is well-structured, spanning from the core event system to the CLI's UI layer with a new React hook and component. The changes are accompanied by a comprehensive set of new tests. I've identified one area for improvement in a useEffect hook that could be made more robust to prevent potential dependency cycles.

gemini-code-assist

Code Review

This pull request introduces a progress bar for long-running MCP tool calls, significantly enhancing user experience by providing real-time updates. While the implementation is generally well-structured, robust, and includes comprehensive unit tests, a high-severity Denial of Service vulnerability was identified. The progress bar rendering logic does not adequately validate numeric progress values from external MCP servers. This oversight could allow a malicious or misbehaving server to provide NaN values, triggering an unhandled RangeError and crashing the CLI. To address this, ensure all values used for UI rendering are finite and valid.

jasmeetsb

Removed

jacob314 · 2026-02-11T22:45:28Z

+  // Always call clearProgress unconditionally so late progress events are
+  // rejected even for calls that never received progress.
+  //
+  // This useEffect IS appropriate — it synchronizes the external


remove the use effect comment.

done. Went further and removed the useEffect entirely, moved the clearProgress logic into the TOOL_CALLS_UPDATE messageBus handler as you suggested in your general comment.

jacob314 · 2026-02-11T22:50:30Z

    const { tool, invocation } = call;

+    // Set callId for MCP progress tracking
+    if (


this is ugly. Would suggest suggest refactoring ToolInvocation to have an optional setCallId method or another mechanism to avoid having to do these checks.

Done.
Added setCallId?(callId: string): void to the ToolInvocation interface in tools.ts.

jacob314 · 2026-02-11T22:51:44Z

+          {message}
+        </Text>
+      )}
+    </Box>


write a couple snapshot based tests to validate this rendering logic.

Done. Added 6 snapsht tests in ToolShared.test.tsx

jacob314 · 2026-02-11T22:52:43Z

+  total,
+  message,
+}) => {
+  const barWidth = 20;


make barWidth a required parameter and pass in a value dependent on the width available when displaying the tool message. Might as well make this a bit larger than 20 chars when the terminal is wide and make sure we don't have wrapping issues when it is small

Changed it. barWidth is now a required prop. calculated in ToolMessage.tsx as 40% of terminal width, clamped between 10 and 40

jacob314 · 2026-02-11T22:53:16Z

        paddingX={1}
        flexDirection="column"
      >
+        {status === ToolCallStatus.Executing && mcpProgress && (


add a snapshot based test that includes a progress indicator. will ensure progress indicators aren't accidentally removed as part of future UI changes.

Done. Added a snapshot test in ToolMessage.test.tsx

jacob314 · 2026-02-11T22:54:00Z

These comments were from /review-frontend audited by Jacob.

Great work on this feature! The implementation of real-time progress for MCP tools is a valuable addition. I have a few suggestions to improve code quality and align with project standards:

Refactor ToolInvocation: The dynamic check for setCallId in ToolExecutor.ts is a bit fragile. Consider adding setCallId?(callId: string): void; to the ToolInvocation interface in packages/core/src/tools/tools.ts. This would allow a clean, type-safe call: invocation.setCallId?.(callId);.
Avoid setState in useEffect: In useToolExecutionScheduler.ts, the useEffect that calls clearProgress could be optimized. Consider moving the clearProgress logic into the TOOL_CALLS_UPDATE handler. This would synchronize the terminal state transitions more directly and avoid an extra render cycle.
Testing Gaps: While useMCPProgress.test.ts is solid, please add a test case to useToolExecutionScheduler.test.ts to verify that mcpProgress is correctly merged into the tool calls for display when they are in the executing status.
Robustness: Nice job on the clamping logic in MCPProgressIndicator (ToolShared.tsx) to prevent potential crashes from String.repeat() with invalid progress values.
Testing Standards: Confirmed that useMCPProgress.test.ts correctly uses the project's internal renderHook and act wrappers.

Please address these points to ensure the implementation is robust and follows our React patterns.

jacob314

Looks good. Approved once these fairly minor comments are addressed.

jasmeetsb · 2026-02-12T13:37:46Z

Thanks for the review! I noticed that upstream #18567 deleted useToolExecutionScheduler.ts (consolidated into useToolScheduler.ts), so I'll port the progress integration to the new file and address all the feedback as part of next push. Thanks.

jasmeetsb · 2026-02-13T21:31:17Z

@jacob314 - Thanks for all the feedback. I think I have addressed it all(see comments above). Upstream #18567 deleted some files, so I ported progress integration from the deleted useToolExecutionScheduler.ts to the consolidated useToolScheduler.ts.

Please let me know if there is any additional feedback.

jacob314 · 2026-02-16T21:56:32Z

+    vi.clearAllMocks();
+  });
+
+  afterEach(() => {


did you mean to do something here?

jacob314 · 2026-02-16T22:03:16Z

This comment was created with /review-frontend after feedback from Jacob Richman that logic appeared to be in packages/cli that should be in packages/core. I believe Gemini CLI should be able to achieve this refactoring accurately if you paste this in as a plan to use to perform it.

This is a great feature, but the current implementation splits the state management across packages/cli and packages/core in a way that breaks encapsulation.

The Architectural Mismatch

The PR adds mcpProgress?: Progress to the ExecutingToolCall type in packages/core/src/scheduler/types.ts, which correctly signals that progress is a property of an executing tool call. However, the ToolScheduler (in Core) never actually populates this field. Instead:

mcp-tool.ts emits a separate side-channel event (CoreEvent.MCPToolProgress).
The CLI's useToolScheduler.ts listens to both the primary TOOL_CALLS_UPDATE event and the new MCPToolProgress event.
The CLI manually stitches these two separate streams of state together using useMCPProgress and a useMemo block.

Why this is problematic

Breaks Encapsulation for other Clients: The ToolScheduler is supposed to be the single source of truth for tool execution state. By doing the state merging in packages/cli, any other client consuming the core package (like the VS Code IDE Companion) will receive mcpProgress: undefined on their ExecutingToolCalls. They would have to duplicate this entire useMCPProgress merging logic to get progress bars to work.
Leaky Abstraction: The CLI shouldn't need to know how to map callIds from progress events to callIds in the tool scheduler array, nor should it be responsible for clearing progress state when a tool transitions to success or error. The Core ToolScheduler already manages these lifecycle transitions.

The Recommended Fix

Please move this logic into packages/core/src/scheduler/tool-scheduler.ts (or tool-executor.ts).

Approach: The ToolScheduler itself should listen to CoreEvent.MCPToolProgress (or the ToolExecutor could pass an onProgress callback to the execute method, similar to updateOutput).
State Update: When progress occurs, the ToolScheduler updates its internal map for that callId to include the mcpProgress data.
Broadcast: It then broadcasts the standard TOOL_CALLS_UPDATE event over the message bus just like it does for any other state change.
Cleanup: The CLI changes to useToolScheduler.ts can be entirely reverted, and useMCPProgress.ts can be deleted. The UI will naturally receive mcpProgress directly on the ExecutingToolCall objects it already gets from the TOOL_CALLS_UPDATE event.

A Note on Performance (Throttling)

Some MCP servers might emit notifications/progress very rapidly (e.g., hundreds of times a second for a fast file download). If you split this out because high-frequency progress events were causing the ToolScheduler to spam the message bus and lag the UI, the solution is still to keep the state in Core. Instead, you should introduce throttling/debouncing in the ToolScheduler's broadcast mechanism (or when emitting the progress event), rather than splitting the state architecture.

Additional Minor Feedback

Type Safety: In packages/core/src/tools/mcp-tool.ts, this.mcpTool is typed as a standard CallableTool (from @google/genai), but is cast to CallableToolWithProgress: const callPromise = progressCallback ? (this.mcpTool as CallableToolWithProgress).callTool(...) : .... This is unsafe. Please consider updating the constructor to accept CallableToolWithProgress (or handle this generic parameter more cleanly).
Uncapped Percentage Display: In ToolShared.tsx, the block progress bar rawFilled visually clamps properly at barWidth, but the text percentage does not (e.g. it can say 150%). Consider whether this should clamp to 100% or explicitly display the raw, uncapped percentage as currently implemented.

jasmeetsb · 2026-02-17T22:39:07Z

@jacob314 - Pushed a new commit addressing your architectural feedback:

Moved MCP progress state entirely into Core
Fixed the CallableToolWithProgress cast with proper constructor types
Capped percentage at 100%
Added 14 new tests covering progress updates, throttling, flush lifecycle, and throw-path safety
Full test suite passing: 632 test files, 10,131 tests, 0 failures. Typecheck, lint, and format all clean.

Display real-time progress bars for MCP tool operations by wiring SDK onprogress callbacks through core events to the CLI UI layer. Closes google-gemini#16934

Move MCP progress tracking into StateManager/Scheduler so all clients get progress via TOOL_CALLS_UPDATE. Delete useMCPProgress hook, fix CallableToolWithProgress cast, cap percentage at 100%.

jacob314

I'm reviewing these core changes vs #19046

jacob314 · 2026-02-18T17:30:30Z

+/**
+ * Payload for the 'mcp-tool-progress' event.
+ */
+export interface MCPToolProgressPayload {


nit: comments about params being optional are not needed as they are implied from the type.

jasmeetsb · 2026-03-07T15:25:56Z

Closing this PR as PR #19046 and #19772 superseded this.

jasmeetsb requested a review from a team as a code owner February 9, 2026 06:44

gemini-code-assist Bot reviewed Feb 9, 2026

View reviewed changes

Comment thread packages/cli/src/ui/hooks/useToolExecutionScheduler.ts Outdated

gemini-code-assist Bot reviewed Feb 9, 2026

View reviewed changes

Comment thread packages/cli/src/ui/components/messages/ToolShared.tsx Outdated

jasmeetsb commented Feb 9, 2026

View reviewed changes

jasmeetsb force-pushed the feature/mcp-progress-reports branch 2 times, most recently from b877feb to 34b445a Compare February 11, 2026 18:55

jacob314 self-requested a review February 11, 2026 21:09

jacob314 reviewed Feb 11, 2026

View reviewed changes

Comment thread packages/cli/src/ui/hooks/useToolExecutionScheduler.ts Outdated

jacob314 reviewed Feb 11, 2026

View reviewed changes

jasmeetsb force-pushed the feature/mcp-progress-reports branch from 34b445a to 7469700 Compare February 12, 2026 03:29

jasmeetsb force-pushed the feature/mcp-progress-reports branch 2 times, most recently from 527ef25 to 0b64680 Compare February 13, 2026 05:20

jasmeetsb force-pushed the feature/mcp-progress-reports branch from 0b64680 to 5f0157e Compare February 14, 2026 00:40

jacob314 reviewed Feb 16, 2026

View reviewed changes

jasmeetsb force-pushed the feature/mcp-progress-reports branch from 5f0157e to 237f6eb Compare February 17, 2026 22:32

jasmeetsb added 2 commits February 17, 2026 14:39

feat(mcp): add MCP tool progress notifications

0ab2544

Display real-time progress bars for MCP tool operations by wiring SDK onprogress callbacks through core events to the CLI UI layer. Closes google-gemini#16934

refactor(mcp): move progress state management from CLI to Core

79a33f6

Move MCP progress tracking into StateManager/Scheduler so all clients get progress via TOOL_CALLS_UPDATE. Delete useMCPProgress hook, fix CallableToolWithProgress cast, cap percentage at 100%.

jasmeetsb force-pushed the feature/mcp-progress-reports branch from 237f6eb to 79a33f6 Compare February 17, 2026 22:39

jasmeetsb requested a review from jacob314 February 17, 2026 22:40

jacob314 enabled auto-merge February 18, 2026 17:22

jacob314 reviewed Feb 18, 2026

View reviewed changes

jacob314 disabled auto-merge February 18, 2026 17:24

jacob314 reviewed Feb 18, 2026

View reviewed changes

SandyTao520 force-pushed the main branch from 4a78a96 to 0bf3a01 Compare February 26, 2026 03:03

jasmeetsb closed this Mar 7, 2026

Conversation

jasmeetsb commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Screenshot

Details

Related Issues

How to Validate

Pre-Merge Checklist

Uh oh!

gemini-code-assist Bot commented Feb 9, 2026

Summary of Changes

Highlights

Footnotes

Uh oh!

jasmeetsb commented Feb 9, 2026

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

jasmeetsb left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jacob314 commented Feb 11, 2026

Uh oh!

jacob314 left a comment

Choose a reason for hiding this comment

Uh oh!

jasmeetsb commented Feb 12, 2026

Uh oh!

jasmeetsb commented Feb 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jacob314 commented Feb 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The Architectural Mismatch

Why this is problematic

The Recommended Fix

A Note on Performance (Throttling)

Additional Minor Feedback

Uh oh!

jasmeetsb commented Feb 17, 2026

Uh oh!

jacob314 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jasmeetsb commented Mar 7, 2026

jasmeetsb commented Feb 9, 2026 •

edited

Loading

jasmeetsb left a comment •

edited

Loading

jacob314 commented Feb 16, 2026 •

edited

Loading

jacob314 left a comment •

edited

Loading