[BUG] 修改文件过程中 快速频繁按 CMD+S 会报文件冲突

[geekeren]

描述你的问题（Describe the bug）

复现路径（To Reproduce）

• 1. 在设置中 打开 保存文件冲突时提示

• 2. 编辑一个文件，在编辑过程中快速且频繁地按 CMD+S （手速一定要快）
• 3. 会出现文件冲突提示

预期表现（Expected behavior）

环境信息（Environment）

• OS: [e.g. macOS 11.2 Apple M1/Windows10/Windows11]
• Browser: [e.g. chrome, safari, electron]
• OpenSumi Version: [e.g. 2.13.0]

[erha19]

@geekeren 目前确实有这个问题，比较容易发生在外部修改的情况，2.26.0 版本追加了一个覆盖的按钮，#2846

如果是框架内的操作，这里感觉可以做一个队列逻辑来保障 Read-Write 的执行顺序上的保障，目前这块在并发情况下是存在问题的，可能出现写过程读的问题

core/packages/file-scheme/src/node/file-scheme-doc.service.ts

Line 31 in 9f3b005

async $saveByChange(

可以尝试修复一下 ~

[geekeren]

@erha19 这里push save task 前有 promise，会不会也有时序问题

core/packages/editor/src/browser/doc-model/editor-document-model.ts

Line 358 in ec4dea4

async save(force = false, reason: SaveReason = SaveReason.Manual): Promise<boolean> {

[bytemain]

时序问题的话放入 promise 队列执行似乎就行了

[erha19]

@geekeren 确实也有的，但是前端执行的路径我不确定是否只有这一处，可能从后端收口处理更直接

[geekeren]

@erha19 后端及时保证了时序，但是保存动作到后端之前，前端就已经有问题了，那应该也不行吧，两个地方都得保证吧。

[erha19]

@erha19 后端及时保证了时序，但是保存动作到后端之前，前端就已经有问题了，那应该也不行吧，两个地方都得保证吧。

这里前端的响应结果最终是受后端影响的，如返回的 state 值

core/packages/file-scheme/src/node/file-scheme-doc.service.ts

Line 54 in 9f3b005

state: SaveTaskResponseState.DIFF,

前端能保证当然也更好，印象中前端有做过类似的队列处理。

[geekeren]

@erha19 尝试为 $saveByContent 加上队列控制,能保证 save之间不串扰，但是发现依旧不能解决问题。

在保存之前加了个 setTimeOut, 发现不加时序控制时，会报另外一个 FileOutOfSync 的错误，而不是 这个错误。

另外有个一个发现，当 server 进行重启时，期间进行一些编辑，恢复以后，这个错误尤其明显。

https://github.com/opensumi/core/blob/d7c8f0cefafb6822ffcb9ff24b5b7ed50ce92f82/packages/file-scheme/src/node/file-scheme-doc.service.ts#L151C6-L151C6

[erha19]

另外有个一个发现，当 server 进行重启时，期间进行一些编辑，恢复以后，这个错误尤其明显。

@geekeren 这个操作就是正常的文件版本判断，服务重启阶段的修改已经属于是不可控的外部修改，会出现版本不匹配的问题，也类似于（文件未保存情况下的外部修改）

我尝试复现看一下

[geekeren]

@erha19 OK，先帮忙看看即使无重启也会报冲突的问题吧

[geekeren]

前端时序还是要解决，这个应该明显是前端时序的问题，频繁保存会有一个 回跳的过程

[geekeren]

@erha19 我把前端时序也加上，好像能解决. 现在不报冲突了

[erha19]

@erha19 我把前端时序也加上，好像能解决. 现在不报冲突了

可以 PR 上来一起看下 ~

[geekeren]

@erha19 你们 format代码是用的 prettier 吗。我启用了 format后代码都乱了

[bytemain]

format 的哪个文件？我这里试一下

[erha19]

@erha19 你们 format代码是用的 prettier 吗。我启用了 format后代码都乱了

嗯，有一些历史代码，可以用 prettier，不要求，能保证代码可读性就行了，格式问题 @bytemain 再看看可以统一格式化一把

[bytemain]

按理说我们是配置了 lint stage 的， commit 的时候会自动 format：

https://github.com/opensumi/core/blob/main/.husky/pre-commit#L4

https://github.com/opensumi/core/blob/main/package.json#L70

[geekeren]

packages/editor/src/browser/doc-model/editor-document-model.ts