Fossil Forum

Bug: discrepancy in wiki timeline comment handling
Login

Bug: discrepancy in wiki timeline comment handling

Bug: discrepancy in wiki timeline comment handling

(1) By Stephan Beal (stephan) on 2021-02-22 02:58:17 [source]

Sometime late last year(?) the format of wiki comments in the timeline was modified to add a prefix character, such that the timeline command/page and alert notifications could look at that character and determine whether the change was the addition of a new page, editing of an old one, or removal of a page.

A few hours ago i noticed some weirdness, per the timeline, in libfossil's wiki page edit history and have been trying to track it down. The symptom is that the + prefix character (indicating that the page was newly-added) is spuriously added to wiki events even when they are edits of an old page.

For example, the following list is from the main fossil tree after deleting the event table's contents and rebuilding using the current trunk:

$ f sql "select objid, comment from event where type='w' order by mtime desc limit 20;"
51267,':Release Build How-To'
50770,'+checkin/fdeebddea7abf6addf1640da01804f230e9a10c2b081b0aafdcac1642d0412ba'
50757,':checkin/fdeebddea7abf6addf1640da01804f230e9a10c2b081b0aafdcac1642d0412ba'
...
49756,'+Test of | in a wiki page name'
...
49931,'+Test of | in a wiki page name'
...
49067,'+branch/andygoth-html-caps'
49068,':branch/andygoth-html-caps'

Note the multiple "misplaced" + prefixes. Also note that last entry, where the ostensibly originating post has a newer mtime than the following edit with a higher RID.

My as-yet-unproven suspicion is that the origin of the problem is:

https://fossil-scm.org/home/file?ci=trunk&name=src%2Fmanifest.c&ln=2435-2440

    prior = db_int(0,
      "SELECT rid FROM tagxref"
      " WHERE tagid=%d AND mtime<%.17g"
      " ORDER BY mtime DESC",
      tagid, p->rDate
    );

If, during a rebuild, the artifacts are not crosslinked in their original time order, prior may not resolve as intended, which affects both the prefix which gets assigned to the comment and whether or not the page's entry gets delta compression applied to it. Generally speaking, there's no guaranty that they will be crosslinked in their original order, so any logic which expects that to be the case seems flawed to me.

Assuming that's the root of the problem, no immediate fix comes to mind other than, perhaps, not doing a tag lookup for a prior version and instead checking the P-tag on the manifest we're crosslinking. i'll try that in a few moments and see if that resolves the issue.

(2.1) By Stephan Beal (stephan) on 2021-02-22 04:48:01 edited from 2.0 in reply to 1 [link] [source]

Assuming that's the root of the problem, no immediate fix comes to mind other than, perhaps, not doing a tag lookup for a prior version and instead checking the P-tag on the manifest we're crosslinking. i'll try that in a few moments and see if that resolves the issue.

Indeed, that was the bug:

$ f sql "select objid, comment from event where type='w' order by mtime desc limit 20;"
...
50770,':checkin/fdeebddea7abf6addf1640da01804f230e9a10c2b081b0aafdcac1642d0412ba'
50757,'+checkin/fdeebddea7abf6addf1640da01804f230e9a10c2b081b0aafdcac1642d0412ba'
...
49756,':Test of | in a wiki page name'
...
49931,'+Test of | in a wiki page name'
...
49067,':branch/andygoth-html-caps'
49068,'+branch/andygoth-html-caps'

Fix is in fossil:ecb705359a58ac32.

Edit: this bug is actually ancient, apparently going back to 2007, but it was never a functional bug until the prefix characters for the timeline comments were added in late 2020. Before that, the worst which could happen was deltification being skipped (no harm done and no outwardly visible side effects).

(3) By Stephan Beal (stephan) on 2021-02-22 03:25:04 in reply to 2.0 [link] [source]

Fix is in fossil:ecb705359a58ac32.

It turns out that we have the same bug in the technote handling (will be fixed momentarily), but we also have an "inverse situation" there, where we check for a subsequent version:

https://fossil-scm.org/home/artifact?name=2acad7b2a202c306&ln=2478-2483

Checking for a subsequent version only works if that newer version has already been crosslinked at the time we're crosslinking this one (which seems very unlikely for most cases). Unlike a check for a prior version, which we can check via the P-card, there's no easy way, aside from a query like that one, to look for a subsequent version.

How to resolve that one is still a mystery to me.

(4.1) By Stephan Beal (stephan) on 2021-02-22 04:44:04 edited from 4.0 in reply to 2.0 [link] [source]

Fix is in fossil:ecb705359a58ac32.

On the other hand: if the parent is a phantom, that fix might (not certain - just speculating) somehow backfire? Deltification silently skips over artifacts smaller than 50 bytes, and a phantom has no bytes, so it seems to be safe enough, but there may be a pothole i've overlooked.

Edit: content_deltify() now explicitly checks for phantoms and is a no-op in that case.