回帖 - fangly

v1.5.5-beta2 子列表状态异常问题

2021-12-26 16:37

beta3 刚刚又遇到和帖子中一样的问题

我往这个地方粘贴图片：

粘贴完之后出现状态异常，重建索引后刚刚的图片粘贴没有成功，缩进没了：

日志：

E 2021/12/26 16:34:07 transaction.go:671: load tree [id=20211226163358-pvy18qf] failed: block not found
E 2021/12/26 16:34:07 transaction.go:671: load tree [id=20211226163407-zaa54cn] failed: block not found

v1.5.5-beta2 子列表状态异常问题

2021-12-26 01:48

又遇到了一个奇怪的情况，和这个帖子相关：

我 ctrl+click 点击这个列表块标要聚焦进去：

一点击之后，这篇文档莫名其妙地就自动关掉了，然后再打开时，发现这个缩进没了，变成这样：

还没找到复现方法

v1.5.5-beta2 子列表状态异常问题

2021-12-25 14:06

刚刚又出现了，本来我红框的位置是缩进进去，正在写里面的内容，写了几个字

然后出现状态异常，重建索引后就缩进回来，刚刚写的几个字没了

太过玄学，重现不出来，我这个是个长列表，可能和列表的保存有一定关系？

反链面板计算逻辑与性能问题

2021-12-02 16:39

好的，内测版 bug 我之后在 github 上报

我还发现一个非内测版也有的 bug，1.5.4 中也能复现，可能很早之前的版本就有了，我就在这里说了，下图中红框中的内容在反链面板中没有显示出来

反链面板计算逻辑与性能问题

2021-12-02 16:20

又发现一个问题，我修改了一个文档 A，文档 A 链接到 paper 文档，之后在 paper 文档的反链面板看这个文档 A 的标题为 untitled

反链面板计算逻辑与性能问题

2021-12-02 15:31

现在一回车就显示：

重建索引后，在文档中再回车一下，又显示状态异常，再重建索引，再回车，又显示状态异常，一直循环

试了下，在某些文档中回车没问题，在某些文档中回车一直会显示状态异常

再试了下，关闭“启动时优先使用已有数据库”，重新打开思源，原先回车会显示状态异常的文档，回车后不会显示状态异常，我猜是数据库有点问题

反链面板计算逻辑与性能问题

2021-11-29 01:36

又出现内核连接中断，这一次和上面的不太一样，没有剪切和新建操作

我是先从一个文档的反链面板点击跳转到另一个文档，然后有做折叠展开操作，之后就内核连接中断了

I 2021/11/29 01:29:34 transaction.go:110: tx [2553ms]
E 2021/11/29 01:29:39 block_query.go:491: query scan field failed: sql: transaction has already been committed or rolled back
E 2021/11/29 01:29:39 block_query.go:491: query scan field failed: sql: Rows are closed
F 2021/11/29 01:30:25 transaction.go:76: transaction failed: %!s(<nil>)

反链面板计算逻辑与性能问题

2021-11-28 22:58

出问题的在哪一步呀，在还没改进之前我要怎么防止这种情况出现呢？

因为最近我每天一打开思源都会做类似的操作，然后几乎都会崩掉，还是有点难受的，我想先知道下怎么防止这种情况出现，比如在什么操作后多等一下之类的？

反链面板计算逻辑与性能问题

2021-11-28 12:57

我把一个文档 A 中某个有很多引用块的列表块 X，剪切到另一个文档 B 中

然后在文档 B 中对这个列表块 X 中的某个列表项进行了一下折叠操作

在文档 A 中其他地方复制了一个块引用

在文档 B 中，在刚才剪切过来的列表块 X 中的某个位置回车新建一个列表项，准备粘贴块引用

然后出现了内核连接中断

重新打开之后，发现文档 A 中那个被剪切的列表块 X 没了，但是文档 B 中也没有这个被剪切的列表块 X，也就是文档 A 写入成功，文档 B 写入不成功，这个列表块 X 就彻底消失了，我只能通过历史功能找回这个列表块 X

这个问题其实最近经常遇到，我每天打开思源的第一件事就会做类似上面的操作

希望大纲有自动换行按钮

2021-11-25 22:48

大纲和反链面板中内容的一大作用是给出足够的语义信息预测该部分的上下文，从而进行定位，大纲中是定位本文档中的内容，反链面板中是定位其他文档中的内容，定位好之后，我再打开悬浮窗查看更多的上下文或者点击跳转详细查看。

而不是将逻辑反过来，先打开悬浮窗查看更多的上下文。

包括之前做“传递型”双链的反链面板修改的时候，也是差不多的逻辑，为了给出足够的语义。

希望大纲有自动换行按钮

2021-11-25 22:31

删除反链“上下文”功能？这是为啥？

把文案换成“自动换行”不可以吗 😭 这个功能还是很有用的呀

希望大纲有自动换行按钮

2021-11-25 22:27

Typora 是自动换行的

默认为了美观不自动换行我觉得没啥问题，但我觉得完全可以搞个和反链面板中一样的按钮

希望大纲有自动换行按钮

2021-11-25 22:11

我看现在的 issue 上写的是“大纲较长时支持鼠标悬浮完整显示”，我觉得这有点问题。

有时候大纲中超过 50% 的内容都超过大纲面板宽度不能完整显示，如果只支持鼠标悬浮完整显示的话，体验还是非常差，一个一个悬浮查看也太崩溃了 😭

而且，“大纲较长时支持鼠标悬浮完整显示”其实现在已经支持了，鼠标放在大纲中的块标上就能完整显示了。更何况，我点击一下标题，跳转到相关位置查看也是一样的，和现在这个 issue 没什么区别。所以，“大纲较长时支持鼠标悬浮完整显示”这个我觉得没有什么意义。V 姐估计想做成 1.2.0 之前时候的悬浮显示，显示一个小框，其实当时我就觉得那个设计没啥用 😂

这个和反链面板中的逻辑是一样的，反链面板中无法完整显示的频率更高，如果没有现在的“上下文按钮”只能悬浮显示的话，体验也是很差的。

反链面板计算逻辑与性能问题

2021-11-25 20:18

上次提到的这个 bug 有定位到问题吗：

反链面板中某个文档（大概率是最新更新的文档）中的反链项都不显示，刷新之后才会显示

反链面板计算逻辑与性能问题

2021-11-25 19:56

有的貌似和大纲没有关系：

W 2021/11/25 19:27:22 conf.go:371: data is writing: 
goroutine 24469 [running]:
runtime/debug.Stack()
	D:/go1.17/src/runtime/debug/stack.go:24 +0x65
github.com/siyuan-note/siyuan-src/kernel/model.WaitForDataWriting()
	D:/88250/siyuan-src/kernel/model/conf.go:371 +0x77
github.com/siyuan-note/siyuan-src/kernel/model.GetDoc({0xc0004ca330, 0x16}, 0x0, {0x0, 0x0}, 0x0, 0xc0006ab5d0)
	D:/88250/siyuan-src/kernel/model/file.go:317 +0x66
github.com/siyuan-note/siyuan-src/kernel/api.getDoc(0xc000636c00)
	D:/88250/siyuan-src/kernel/api/filetree.go:525 +0x2d1
github.com/gin-gonic/gin.(*Context).Next(...)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
github.com/siyuan-note/siyuan-src/kernel/model.CheckAuth(0xc000636c00)
	D:/88250/siyuan-src/kernel/model/session.go:94 +0x467
github.com/gin-gonic/gin.(*Context).Next(...)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
github.com/gin-contrib/sessions.Sessions.func1(0xc000636c00)
	D:/gogogo/pkg/mod/github.com/gin-contrib/sessions@v0.0.3/sessions.go:52 +0x18d
github.com/gin-gonic/gin.(*Context).Next(...)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
github.com/gin-contrib/gzip.(*gzipHandler).Handle(0xc0007ac0f0, 0xc000636c00)
	D:/gogogo/pkg/mod/github.com/gin-contrib/gzip@v0.0.3/handler.go:60 +0x2ed
github.com/gin-gonic/gin.(*Context).Next(...)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
github.com/gin-gonic/gin.CustomRecoveryWithWriter.func1(0xc000636c00)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/recovery.go:99 +0x82
github.com/gin-gonic/gin.(*Context).Next(...)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
github.com/gin-gonic/gin.(*Engine).handleHTTPRequest(0xc0002d81a0, 0xc000636c00)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/gin.go:489 +0x63e
github.com/gin-gonic/gin.(*Engine).ServeHTTP(0xc0002d81a0, {0x21d4348, 0xc000138540}, 0xc000636b00)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/gin.go:445 +0x1c5
net/http.serverHandler.ServeHTTP({0x21d0708}, {0x21d4348, 0xc000138540}, 0xc000636b00)
	D:/go1.17/src/net/http/server.go:2878 +0x43b
net/http.(*conn).serve(0xc00071e0a0, {0x21df640, 0xc0007ddcb0})
	D:/go1.17/src/net/http/server.go:1929 +0xb08
created by net/http.(*Server).Serve
	D:/go1.17/src/net/http/server.go:3033 +0x4e8

反链面板计算逻辑与性能问题

2021-11-25 19:28

日志里又发现了新东西：

W 2021/11/25 19:20:54 conf.go:371: data is writing: 
goroutine 20570 [running]:
runtime/debug.Stack()
	D:/go1.17/src/runtime/debug/stack.go:24 +0x65
github.com/siyuan-note/siyuan-src/kernel/model.WaitForDataWriting()
	D:/88250/siyuan-src/kernel/model/conf.go:371 +0x77
github.com/siyuan-note/siyuan-src/kernel/model.Outline({0xc00129c030, 0x16})
	D:/88250/siyuan-src/kernel/model/outline.go:16 +0x3e
github.com/siyuan-note/siyuan-src/kernel/api.getDocOutline(0xc001028600)
	D:/88250/siyuan-src/kernel/api/outline.go:28 +0xf8
github.com/gin-gonic/gin.(*Context).Next(...)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
github.com/siyuan-note/siyuan-src/kernel/model.CheckAuth(0xc001028600)
	D:/88250/siyuan-src/kernel/model/session.go:94 +0x467
github.com/gin-gonic/gin.(*Context).Next(...)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
github.com/gin-contrib/sessions.Sessions.func1(0xc001028600)
	D:/gogogo/pkg/mod/github.com/gin-contrib/sessions@v0.0.3/sessions.go:52 +0x18d
github.com/gin-gonic/gin.(*Context).Next(...)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
github.com/gin-contrib/gzip.(*gzipHandler).Handle(0xc0007ac0f0, 0xc001028600)
	D:/gogogo/pkg/mod/github.com/gin-contrib/gzip@v0.0.3/handler.go:60 +0x2ed
github.com/gin-gonic/gin.(*Context).Next(...)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
github.com/gin-gonic/gin.CustomRecoveryWithWriter.func1(0xc001028600)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/recovery.go:99 +0x82
github.com/gin-gonic/gin.(*Context).Next(...)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
github.com/gin-gonic/gin.(*Engine).handleHTTPRequest(0xc0002d81a0, 0xc001028600)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/gin.go:489 +0x63e
github.com/gin-gonic/gin.(*Engine).ServeHTTP(0xc0002d81a0, {0x21d4348, 0xc000cb62a0}, 0xc001028200)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/gin.go:445 +0x1c5
net/http.serverHandler.ServeHTTP({0x21d0708}, {0x21d4348, 0xc000cb62a0}, 0xc001028200)
	D:/go1.17/src/net/http/server.go:2878 +0x43b
net/http.(*conn).serve(0xc00035af00, {0x21df640, 0xc0007ddcb0})
	D:/go1.17/src/net/http/server.go:1929 +0xb08
created by net/http.(*Server).Serve
	D:/go1.17/src/net/http/server.go:3033 +0x4e8

我的复现方式是：复制一个文档块引用，粘贴，这时候 CPU 占用很高，应该是在后台计算，这个时候鼠标马上移动到某个引用块上，这时候后台还在计算，引用块是没有反应的。然后日志中就会有上面的内容。

类似这样操作：

反链面板计算逻辑与性能问题

2021-11-24 16:41

偶尔假死的时间比较长，看了一下日志，有下面这个信息，是正常的吗？

E 2021/11/24 16:36:59 block_query.go:111: sql query failed: SELECT id FROM blocks WHERE parent_id = ?%!(EXTRA *errors.errorString=sql: transaction has already been committed or rolled back)
E 2021/11/24 16:38:02 block_ref_query.go:432: query scan field failed: sql: Rows are closed

尤其是 query scan field failed: sql: Rows are closed 这一条，我发现自从更新 alpha2 之后，日志里面有不少。

完整 log：

log.zip

顺带提一下，a2 经常出现反链面板第一条内容为空的情况（除了第一条，后面的内容都正常），“传递型”和“关联型”都出现过这种情况，刷新反链面板之后恢复正常，而且有点难复现 😂 ：

反链面板计算逻辑与性能问题

2021-11-24 13:24

alpha2 事务实现改了之后我觉得舒服了很多，但反链面板的性能上我体验下来感觉还是有提升空间

200 个反链的文档第一次加载的时候比 alpha1 快一些，但还是要差不多 8 秒钟才能加载出来，第一次加载时候的时间不知道能否再压榨得短一些 😂

第一次 8 秒钟加载出来后，打开别的文档，再返回来，反链面板能秒出现，这部分应该是 alpha2 新优化的，这个非常舒服，我猜是检查了“数据是否变动”，没变动就不请求了？

但是过几分钟后再打开这个有 200 个反链的文档又要 8 秒钟加载，这个几分钟我也不清楚是多久，有时候有的文档上百个反链几分钟后仍然秒加载，但有时候有的文档几分钟后又要好久才能加载（都没有修改过，没有数据变动），不知道这里是不是有 bug？

反链面板计算逻辑与性能问题

2021-11-23 12:33

我没太理解，好像说的不是一个问题 😂

帖子中的第二个问题可能和“数据是否变动”有关

但第一个问题和这个没关系吧，无论“数据是否变动”，都没有请求的意义吧，可以看下面这个录屏，我反链面板都关了，打开一个有 199 个反链的文档后，CPU 开始高占用，开始计算反链，这里的计算请求没有必要吧：

现在时不时地因为后台计算导致引用块悬浮窗没反应，引用块搜索没反应，要等老半天，而且出现频率很高，有点严重影响使用了，相比 1.4.6 以前，体验流畅度差了不少 😭

反链面板计算逻辑与性能问题

2021-11-23 11:20

帖子中的第一个问题应该是比较好优化的吧，在我关掉反链面板后，之后打开文档就不要触发反链计算请求，现在应该还是会请求的

打开一个嵌入块很多的文档后软件直接不能用了，且无法关闭软件

2021-11-19 23:48

在标题操作上的性能和 v1.4.6 相比还是差得有点多：

v1.4.6，大纲是秒变化：

v1.5.3，大纲要 50 秒才能变化，在等待大纲变化的期间，能写东西，但是所有引用块都失效，切换到其他文档大纲也不会变化，处于“半假死”状态：

聚焦后写东西，返回去后丢内容

2021-11-17 20:54

应该阻塞比较好，在面包屑上切换的时候阻塞获取数据，用时间换取安全性 😄

小优化：反链展示对「锚文本是否独占了一个节点」的判定优化 Ⅱ

2021-11-17 18:10

👍 标题和列表在反链逻辑上应该是统一的

打开一个嵌入块很多的文档后软件直接不能用了，且无法关闭软件

2021-11-14 14:26

除了大纲的反应特别慢，反链面板的反应也特别的慢，对于一个有 100 多条反链的文档，引用块悬浮窗一秒不到就出来了，而反链面板却要 5 秒以上才能出来，我不太理解为什么引用块悬浮窗那么快而反链面板却要这么久，两者本来应该差不太多吧

打开一个嵌入块很多的文档后软件直接不能用了，且无法关闭软件

2021-11-14 14:03

可以看下面这个录屏，我只是把一个三级标题变成一级标题(当然这对底层.sy 文件来说意味着要大改结构)，大纲反应过来要等 1 分多钟（这个视频有 1 分多钟，在中间可以看到任务管理器中思源 CPU 占用非常高，大纲反应过来之后 CPU 占用迅速降低）：

这个要在大库下才能复现，小库下复现不了

打开一个嵌入块很多的文档后软件直接不能用了，且无法关闭软件

2021-11-14 13:25

我之前随便在一个新的工作空间试了下，忘了做了什么操作，日志中有以下记录，不知道能不能看出什么东西(前面几个 rebuilt database 是我主动重建索引的，我把一些东西复制到新工作工作空间，然后重建索引)：

I 2021/11/14 12:43:47 box.go:499: rebuilt database for notebook [20210820214849-sbwv4pi] in [13.83s], tree stat [count=295, size=8.4 MB]
I 2021/11/14 12:43:51 box.go:499: rebuilt database for notebook [20210927211858-cnulnll] in [3.55s], tree stat [count=57, size=1.1 MB]
I 2021/11/14 12:44:50 box.go:499: rebuilt database for notebook [20210820214849-sbwv4pi] in [15.37s], tree stat [count=354, size=9.4 MB]
I 2021/11/14 12:44:54 box.go:499: rebuilt database for notebook [20210927211858-cnulnll] in [3.69s], tree stat [count=57, size=1.1 MB]
W 2021/11/14 12:46:36 conf.go:370: data is writing
I 2021/11/14 12:47:17 box.go:499: rebuilt database for notebook [20210820214849-sbwv4pi] in [63.57s], tree stat [count=704, size=22 MB]
E 2021/11/14 12:47:32 database.go:1084: begin tx failed: database is locked
  goroutine 79128 [running]:
runtime/debug.Stack()
	D:/go1.17/src/runtime/debug/stack.go:24 +0x65
github.com/siyuan-note/siyuan-src/kernel/sql.BeginTx()
	D:/88250/siyuan-src/kernel/sql/database.go:1084 +0x51
github.com/siyuan-note/siyuan-src/kernel/model.BuildBlockPath({0xc0083c8540, 0x16})
	D:/88250/siyuan-src/kernel/model/blockinfo.go:187 +0x65
github.com/siyuan-note/siyuan-src/kernel/api.getBlockBreadcrumb(0xc000ae4200)
	D:/88250/siyuan-src/kernel/api/block.go:218 +0xf8
github.com/gin-gonic/gin.(*Context).Next(...)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
github.com/siyuan-note/siyuan-src/kernel/model.CheckAuth(0xc000ae4200)
	D:/88250/siyuan-src/kernel/model/session.go:93 +0x467
github.com/gin-gonic/gin.(*Context).Next(...)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
github.com/gin-contrib/sessions.Sessions.func1(0xc000ae4200)
	D:/gogogo/pkg/mod/github.com/gin-contrib/sessions@v0.0.3/sessions.go:52 +0x18d
github.com/gin-gonic/gin.(*Context).Next(...)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
github.com/gin-contrib/gzip.(*gzipHandler).Handle(0xc00066ef60, 0xc000ae4200)
	D:/gogogo/pkg/mod/github.com/gin-contrib/gzip@v0.0.3/handler.go:60 +0x2ed
github.com/gin-gonic/gin.(*Context).Next(...)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
github.com/gin-gonic/gin.CustomRecoveryWithWriter.func1(0xc000ae4200)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/recovery.go:99 +0x82
github.com/gin-gonic/gin.(*Context).Next(...)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/context.go:165
github.com/gin-gonic/gin.(*Engine).handleHTTPRequest(0xc000502820, 0xc000ae4200)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/gin.go:489 +0x63e
github.com/gin-gonic/gin.(*Engine).ServeHTTP(0xc000502820, {0x1441b08, 0xc000c6a1c0}, 0xc000ae4000)
	D:/gogogo/pkg/mod/github.com/gin-gonic/gin@v1.7.4/gin.go:445 +0x1c5
net/http.serverHandler.ServeHTTP({0x143dec8}, {0x1441b08, 0xc000c6a1c0}, 0xc000ae4000)
	D:/go1.17/src/net/http/server.go:2878 +0x43b
net/http.(*conn).serve(0xc000708000, {0x144cf00, 0xc000541410})
	D:/go1.17/src/net/http/server.go:1929 +0xb08
created by net/http.(*Server).Serve
	D:/go1.17/src/net/http/server.go:3033 +0x4e8
I 2021/11/14 12:47:43 working.go:94:

现在我每次操作标题都得非常小心，要等大纲反应过来了才放心进行其他操作，不然很容易假死，而现在大纲反应太慢了，最近我对标题的操作又比较多，所以用起来比较心累 😂

打开一个嵌入块很多的文档后软件直接不能用了，且无法关闭软件

2021-11-14 11:37

假死情况目前还是存在，最后发给您的复现方法在 1.5.2 中依然能复现

下面这个图中，我只是删除了这个文档中的所有内容，就假死了，我猜测是写入数据一直阻塞着：

过了一段时间，弹出内核连接中断：

关掉思源，重启后，发现文档中的内容没有被删除，应该是没有成功写入数据

复现这个假死问题的一个要点是“大纲的显示与文档真正的内容不匹配”的时候做一些操作，比如说之前的复现方法中，改变标题层级，在大纲还没有反应过来的时候，将列表转换为段落，此时一定会假死，如果大纲此时反应过来了，一般不会假死。

而在小库下，大纲反应很快，因此很难做到大纲与文档真正内容不匹配，也就很难复现。

“大纲的显示与文档真正的内容不匹配”这个当然是表面现象，本质肯定是其他原因。

还有 1.4.7 之后大纲的反应速度在大库下明显比以前慢了很多，这也导致了 1.4.6 之前在大库下也没法复现，而 1.4.7 之后在大库下很容易复现上面的假死问题，说不定这个问题以前版本也存在，只是以前版本大纲反应太快了，没有人有那么快的手速可以在大纲还没反应过来的时候进行其他操作。“大纲的反应速度在大库下慢”这当然也是表面现象，本质应该也是有其他原因。或许可以往提高大纲反应速度的方向修复看看？

嵌入块在嵌入另外一个笔记之后，如何在后来的笔记中快速找到嵌入块原来所在的笔记？

2021-11-13 22:26

要回到原来的位置的话，点击嵌入块，再 ctrl+click 点击面包屑，就回到嵌入块原文的位置了

我觉得你貌似对嵌入块的理解有偏差，你所展示的图片中，应该是《住宅的健康声环境》中的块嵌入到《2021-11-13》中，你好像理解反了