Block ID is unstable when writing content in raw HTML
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
Research direction
Start by tracing how raw HTML blocks are parsed and assigned IDs during graph re-indexing, then compare that path with ordinary Markdown blocks. Reproduce the issue using the two-page graph and the listed re-index or migration steps; done means the HTML block ID remains unchanged and its reference continues to resolve.
Written by the indexing model from the issue text.
Description
Search first
- I searched and no similar issues were found
What Happened?
This is migrated from #12323. It can be reproduced in logseq-og-1.0.0
I found that for blocks written in raw HTML, their block ID changes every time when reading the graph. for example the following two-page graph:
- "page 1.md"
- markdown
- id:: 6962f273-6224-4018-8bef-0331aa4d0e36
| A | B | C |
|---|---|---|
| 1 | 2 | 3 |
| 4 | 5 | 6 |
| 7 | 8 | 9 |
- html
- <table border="1" class="dataframe">
id:: 6962f467-6626-4f9b-8830-31728a8d75be
<thead>
<tr>
<th>A</th>
<th>B</th>
<th>C</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>2</td>
<td>3</td>
</tr>
<tr>
<td>4</td>
<td>5</td>
<td>6</td>
</tr>
<tr>
<td>7</td>
<td>8</td>
<td>9</td>
</tr>
</tbody>
</table>
-
Please note that I did not write id:: XXXX manully. They are generated by logseq.
- "page 2.md"
- markdown
- ((6962f273-6224-4018-8bef-0331aa4d0e36))
- html
- ((6962f467-6626-4f9b-8830-31728a8d75be))
-
In page 2, I referenced to the blocks in page 1 and it works fine.
However, when I migerate the whole graph (folder) to another machine, the reference to HTML block breaks.
Returning to page 1, I found the block ID is re-generated and is different from the previous one.
On the original machine, the block ID is valid, so the reference is valid.
But if I click "Re-index" on the original machine, the block ID is also changed:
Causing the block reference breaks:
Reproduce the Bug
- write a block with HTML
- reference that block
- re-index the graph or migrate it to another machine
- get broken block reference
Expected Behavior
I expect block reference is stable no matter what I do with the graph (excluding modifing the reference itself)
Screenshots
No response
Desktop or Mobile Platform Information
Windows 11, Desktop OG app 1.0.0
Additional Context
No response
Are you willing to submit a PR? If you know how to fix the bug.
- I'm willing to submit a PR (Thank you!)
- Dominant language
- Clojure
- Stars
- 297
- Forks
- 52
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from logseq/og
-
Difficulty 4/5 3-5 days Newbie friendliness 62/100
-
Difficulty 3/5 1-2 days Newbie friendliness 76/100
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
clojure-lsp/clojure-lsp#2469 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
.Team/Metabot Priority:P3
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
needs triage
Difficulty 1/5 Under an hour Newbie friendliness 90/100