HttpRepl: CRASH: ConsoleManager throws ArgumentOutOfRangeException while using the REPL interactively

I regularly encounter that the HTTP REPL suddendly crashes while I am typing commands in the REPL. From the error message below I suspect this happens when I type beyond the width of my terminal window. I also suspect that this happens when I have edited the command along the way (i.e. corrected the typed command with pressing backspace, navigating back and forth with the arrow-keys, etc.)

The REPL throws an ArgumentOutOfRangeException from the ConsoleManager class, Method: MoveCaret(Int32 position).

...> get someapi/somepath/someendpoi
Unhandled exception. System.ArgumentOutOfRangeException: The value must be greater than or equal to zero and less than the console's buffer size in that dimension. (Parameter 'top')
Actual value was 49.
   at System.ConsolePal.SetCursorPosition(Int32 left, Int32 top)
   at Microsoft.Repl.ConsoleHandling.ConsoleManager.MoveCaret(Int32 positions) in /_/src/Microsoft.Repl/ConsoleHandling/ConsoleManager.cs:line 125
   at Microsoft.Repl.Input.InputManager.StartAsync(IShellState state, CancellationToken cancellationToken) in /_/src/Microsoft.Repl/Input/InputManager.cs:line 339
   at Microsoft.HttpRepl.Program.Start(String[] args, IConsoleManager consoleManager, IPreferences preferences, ITelemetry telemetry) in /_/src/Microsoft.HttpRepl/Program.cs:line 96
   at Microsoft.HttpRepl.Program.Main(String[] args) in /_/src/Microsoft.HttpRepl/Program.cs:line 27
   at Microsoft.HttpRepl.Program.<Main>(String[] args)

dotnet --info

.NET SDK (reflecting any global.json):
 Version:   5.0.100
 Commit:    5044b93829

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19042
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.100\

Host (useful for support):
  Version: 5.0.0
  Commit:  cf258a14b7

.NET SDKs installed:
  3.1.402 [C:\Program Files\dotnet\sdk]
  5.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

dotnet tool list --global

Package Id                            Version                  Commands
------------------------------------------------------------------------------------------
microsoft.dotnet-httprepl             5.0.0                    httprepl

About this issue

  • Original URL
  • State: open
  • Created 4 years ago
  • Comments: 20 (15 by maintainers)

Most upvoted comments

@Tragetaschen Can you try the new 5.0.2 preview?

dotnet tool update microsoft.dotnet-Httprepl --version 5.0.2-preview.21056.2 --global

It should act better… but I’d like to see if it completely fixes the issue for you.

Note that it might not be available for you right away as I just published it.

Edit: On further inspection I can see there’s a few more problems than the one I identified in this fix. I’ll see about getting a more complete fix out later today.

OK, so here’s what I’ve been able to determine. There’s (at least) two different issues going on here, both with the same (or related) root causes.

  1. There’s an assumption in the ConsoleManager/InputManager that the caret position in the host (cmd, powershell, whatever) will always move “forward” (to the right and down) when Console.Write(string) is called. But this isn’t necessarily true. Specifically, in some hosts the caret won’t move when you type a character in the last position on the row. It doesn’t move until you add the next character (the one that would be the first one on the next line). This leads to several problems where the tool thinks the cursor is somewhere within the line rather than at the end of the line. Depending on what your next action is - typing a character, moving the cursor, etc - the exception can vary.
  2. There’s another assumption that when the line wrapping occurs, the Console.CursorTop will move to the next line. This is true if you’re not at the end of the buffer. But if you’re at the end of the buffer, everything is shifted up and you stay on the same line. This throws off the calculations for the current caret position. This problem manifests itself differently between hosts because of the varying size (or definitions) of the buffers. For example: cmd.exe running by itself has a large buffer height (9001) and so it takes a long time for you to run into this. But cmd.exe running within Windows Terminal has a buffer height of the size of the window, so you run into it more quickly.

It seems that the tie between the host’s cursor position and the ConsoleManager’s cursor position (which is basically just an index on an array, not a 2D position like the host) is not as clear as it was thought to be originally. Specifically, this method, which uses before/after snapshots of the host’s positions to update the tool’s position whenever a change or set of changes are made:

https://github.com/dotnet/HttpRepl/blob/10598988b9404dd6c3f0ab3850505cd919b8b5b3/src/Microsoft.Repl/ConsoleHandling/ConsoleManager.cs#L195-L205

Caret in this case is just a wrapper around Console.CursorLeft and Console.CursorTop:

https://github.com/dotnet/HttpRepl/blob/10598988b9404dd6c3f0ab3850505cd919b8b5b3/src/Microsoft.Repl/ConsoleHandling/ConsoleManager.cs#L15

There’s another piece that’s definitely off here as well: We are updating the cursor position with these methods even in the case of things being written to the screen as part of command execution (e.g. error messages, response content, etc). It’ll never be right in those cases because of all the escape codes contained in the content. But we reset it every time at the end of a command execution anyway. So its unnecessarily and incorrectly tracked… and then reset.

We could - maybe - split the way that is implemented between user input and system output, and then use the length of what the user entered to calculate the tool’s caret position rather than using the host’s position. Or maybe we could rely on the reset mentioned in the last paragraph to not have to do a split and just do it that way regardless.

There might be issues with supporting other languages/keyboards if we use the string length… but I think those would already be an issue with the current implementation (disconnect between the number of chars in a .NET string and the number of characters printed to the screen in a console).

Going to have to ponder this, but wanted to put all the info out there in case anyone else had any thoughts.

Another exception message, this time when editing a previously run command (by hitting up-arrow), again exception was throws as soon as the caret moved one beyond the current width of the window:

Unhandled exception. System.ArgumentOutOfRangeException: The value must be greater than or equal to zero and less than the console's buffer size in that dimension. (Parameter 'top')
Actual value was 49.
   at System.ConsolePal.SetCursorPosition(Int32 left, Int32 top)
   at Microsoft.Repl.ConsoleHandling.ConsoleManager.MoveCaret(Int32 positions) in /_/src/Microsoft.Repl/ConsoleHandling/ConsoleManager.cs:line 125
   at Microsoft.Repl.Input.InputManager.StartAsync(IShellState state, CancellationToken cancellationToken) in /_/src/Microsoft.Repl/Input/InputManager.cs:line 339
   at Microsoft.HttpRepl.Program.Start(String[] args, IConsoleManager consoleManager, IPreferences preferences, ITelemetry telemetry) in /_/src/Microsoft.HttpRepl/Program.cs:line 96
   at Microsoft.HttpRepl.Program.Main(String[] args) in /_/src/Microsoft.HttpRepl/Program.cs:line 27
   at Microsoft.HttpRepl.Program.<Main>(String[] args)