Data Editor Windows Failure to Open Irregular Sized File

[stricklandrbls]

Bug Overview

The issue #819 described an issue with the data editor's ability to handle uncommonly sized files. More specifically, file sizes of <= 1 byte. A branch was created and a fix was developed and merged in #822. After the merge of the PR, an issue was found that was specific to the Windows environment, both 10 & 11.

The issue is that there are intermittent instances when the data editor will properly handle uncommonly sized files but in most cases, the data editor's Omega Edit session never completely initiates. This causes the data editor to not display properly and upon exit, the localhost bound gRPC server ( Omega Edit ) remains active. The typical workflow is that Omega Edit servers are exited when all instances of the data editor are closed.

Due to the lingering Omega Edit server, no more data editors can properly initiate and log an ERROR associated with interference with an existing PID file.

Current Work Arounds

Currently, there are two different go-to workarounds for being able to open data editor instances after entering this state.

Workaround 1
^{Optional: Open the task manager and verify no "OpenJDK Platform binary" processes are listed as sub-processes under the Visual Studio Code main process. If so, end the task.}

• Close and reopen VSCode.
• Start another instance of the data editor.

Workaround 2

• Perform the Optional step from workaround 1.
• Close VSCode
• Using the Windows file manager, navigate to C:\Users<username>\AppData\Roaming\xdg.data\omega_edit and delete the contents of this directory.
• Reopen VSCode and start another instance of the data editor.

[arosien]

Perhaps there should be a "Reset Data Editor" action available that kills anything running and deletes any transient data like lock files. Or perhaps a similar "Reload Data Editor" action.

[scholarsmate]

I added specific test cases for empty, single-byte, and two-byte files to the Ωedit™ test suite (ctc-oss/omega-edit#731) and the tests pass.

@arosien, Ωedit™ doesn't use lock files, nor any transient data, but it does use IP ports, and PID files. All the server management code is in the client (https://github.com/ctc-oss/omega-edit/blob/main/packages/client/src/server.ts). A review of that code would be welcome. I've been relying on the operating system to kill running servers, though I have attempted to shutdown the server using an API instead, but haven't gotten them to pass the test cases (ctc-oss/omega-edit#606). I have also been thinking about having the server timeout and shutdown if it hasn't received a heartbeat request from the client after some amount of time to handle the case where VSCode gets shutdown hard. It should be possible to reconnect to a session given the same session ID, though that logic hasn't been put in the extension. The extension just attempts to create a new session each time and not attempt a reconnect/reload.

It's not too hard to log (persist to storage) all the change requests that come into Ωedit™ and replay them in another instance. I have example code that does just that, playing and replaying session changes, using JSON as the serialization format (because it's easy to read and manipulate, but for production I'd probably serialize the protocol buffer messages to a google::protobuf::io::CodedOuputStream for safety and efficiency). By default though it's not logging all change requests and changes are being held in memory.

[stricklandrbls]

I believe this issue was fixed with a commit from a couple weeks back. When I find out which commit resolved this issue I will close this.

Not sure why it wasn't referenced w/ a PR.

@scholarsmate was this possibly an Omega Edit server fix?

[scholarsmate]

I added test cases for these in OmegaEdit, but there were no server-side fixes.

[stricklandrbls]

The commit to main that resolved this issue was af689c7

I didn't add the Closes ### to that commit message.