codesandbox / codesandbox/codesandbox-client

Investigate interaction of live sandboxes functionality with code formatting functionality

Open
#5,902 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Live Needs More Info
Dominant language
JavaScript
Stars
13.6k
Forks
2.4k
Avg merge
6d 19h
Merged PRs (30d)
2

Description

Background info:

A common error we get related to our live sandboxes has to do with the operational transformation library we use: The operation's base length must be equal to the string's length. String length: 934, base length: 926

For many errors, the expected string length and base length are often off by a small number of characters relative to the size of the code chunk being processed - sometimes even off by just one character - which could potentially be explained by characters being lost/added in formatting changes. Some investigation into the details of some of the incidents from AppSignal and Sentry seem to initially confirm this. We want to take a closer look at a few things and how it interacts with/affects the text operations we send between the client and server:

  • autoformatting/"prettifying" the code:
    • prettifying the code can change the content by a small amount if it's adding a newline at the end of the file, if it's changing code to be on one line instead of two lines or vice versa, etc.
    • there are some issues open on how the prettifier can even remove brackets in some cases, which would further support the idea that maybe some characters go missing at some point in the process of being prepped and sent to the lives server (see here and here
  • how newlines and ends of lines are calculated and dealt with
    • different operating systems deal with newlines in strings differently: some use \n and some use \r\n
    • we have code to deal with this but we want to make sure it's being used consistently and in the right places

The code that determines a diff of a file (to create the text operation to send to the server) is found here: https://github.com/codesandbox/codesandbox-client/blob/master/packages/common/src/utils/diff/index.ts#L14

This function takes two strings, and will give back the operations as a diff.

Actions:

  • test whether the getTextOperation above functions the same with \n and \r\n as line endings
  • wherever the functionality is for prettifying/formatting code, find out when it happens in the flow as it relates to code being prepped and transformed (like in the function above) for sending to the server, and whether this could potentially change the text content that is expected by the client/server
  • how and where do we make the decisions of what code is being "selected" to be sent to the server, which mentions lines and columns (and could be affected by changes in formatting) - see this incident in Sentry, filter breadcrumbs by "ot" and look at the second to last one
  • do we normalize code to have a single carriage return \n before applying operations, and if so, when does it happen related to this flow
  • one last thing to consider, if someone has autosave and autoformatting turned on, how does that interact with the flow

Potentially related issues:

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with packages/common/src/utils/diff/index.ts and the getTextOperation function. Test its behavior with \n and \r\n, then trace where prettifying, line-ending normalization, code selection, and autosave occur relative to operations sent to the server; review the Sentry incident breadcrumbs filtered by "ot". Done means documenting whether formatting can produce mismatched text lengths and identifying the affected flow.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
full-stack
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.