Skip to content

fix(cli-repl): multiline dots and prompts #2191

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

kraenhansen
Copy link
Contributor

@kraenhansen kraenhansen commented Oct 4, 2024

For now this PR adds a failing test demonstrating how writing a multiline command prints an extraneous prompt before multiline dots (the "..." prefixed after every line-break in the input).

Arguably not a huge bug, but I do believe it's the reason for this comment:

// in some situations the prompt occurs multiple times in the line (but only in tests!)
and this failure:

FLE tests 7.0+ allows explicit enryption with bypassQueryAnalysis: AssertionError: expected '... ... ... ... \n' to include 'ghjk'

And the systematic failure on #2171

@kraenhansen kraenhansen added the bug Something isn't working label Oct 4, 2024
@kraenhansen kraenhansen force-pushed the kh/multiline-dots-and-prompts branch from fc6fe8b to f1f6d57 Compare October 4, 2024 15:27
@kraenhansen kraenhansen self-assigned this Oct 4, 2024
.substring(outputOffsetBefore, outputOffsetAfterDots)
.trim();
// Expect just the multiline dots
expect(output.startsWith('... ...')).equals(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test does fail for me, locally, but unfortunately I think that's actually expected behavior? The first prompt printed by mongosh in response to the .writeInputLine() call is a regular prompt, not a multiline prompt, but that's happening because the first line of the writeInputLine() argument is empty/whitespace-only.

That being said ... yeah, there's a good chance that that causes the flakiness in the FLE test at least. I feel like it's probably a good idea to just always .trim() the input to .writeInputLine()? For raw input, there's always .writeInput() itself

Copy link
Contributor Author

@kraenhansen kraenhansen Oct 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch! Trimming the input to writeInputLine fixed the issue 👍

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants