Item12843: Renaming a topic results in broken links sometimes

pencil
Priority: Urgent
Current State: Closed
Released In: n/a
Target Release:
Applies To: Extension
Component: SolrPlugin
Branches:
Reported By: LeilaPearson
Waiting For:
Last Change By: MichaelDaum
This is a weird one and I'm not sure it is caused by this extension - it's just a guess. Please re-categorize as needed.

The problem I'm seeing - and I've reproduced it both on my 1.1.9 site and Michael's demo site but not on foswiki.org - is that sometimes when I rename a topic it doesn't find all the links to that topic and rename them.

Here are the steps I used to reproduce this:
  1. Create a topic - for example TestTopic70
  2. Inside TestTopic70 type the text "TestTopic71" and save.
  3. Click on the TestTopic71 link to create a new TestTopic71 topic in the same web.
  4. Save the new TestTopic71 topic.
  5. Move/Rename TestTopic71 to TestTopic72

Expected behavior:
  • TestTopic70 should be listed on the move/rename page in the list of pages to be updated with the new link, and when you confirm the rename that page should be updated to with a link to TestTopic72.

Actual behavior:

As mentioned, I've reproduced this numerous times on both my Foswiki 1.1.9 site and Michael's demo site. I might do this 5 times in a row, but then I go back and repeat the same set of steps again and it doesn't happen the next 5 times in a row.

I consider this problem to be fairly serious because it results in broken links.

-- LeilaPearson - 03 Apr 2014

Did some digging. Reclassifying this a SolrPlugin issue since it is using SOLRSEARCH to find the outgoing links.

I think I've figured out the cause and also why it isn't 100% reproducible.

In SolrPlugin/Index.pm the _addLink function will not add an outgoing link to a topic's search index info if the destination topic doesn't exist. The problem is the topic may be created later and when it is, the topics that refer to it won't have their index info updated with the now-valid link - at least not until they get reindexed for some reason.

Why isn't this 100% reproducible? I think it's because the original topic isn't indexed immediately. Sometimes it happens to get indexed after the topic it refers to is created, and other times it gets indexed before the topic it refers to is created.

-- LeilaPearson - 07 Apr 2014

Unfortunately this doesn't seem to fully fix the problem. Just created a group, used the group on on of my WebPreferences pages, and then reanmed the group. The WebPreferences page wasn't found or updated. Doing a Solr search, it seems that the WebPreferences pages aren't indexed.

-- LeilaPearson - 08 Apr 2014

So it seems that by default SolrPlugin is configured with a long list of topics to skip:

Removing WebPreferences from the above list should fix the issue I was seeing with links in WebPreferences not being updated.

Revisiting the whole list with the following two questions in mind seems like a good idea:
  • Is the topic likely to contain any outgoing links that should be updated when the destination topic is renamed?
  • Would indexing this topic have any undesired effects?

-- LeilaPearson - 09 Apr 2014

You are absolutely right in both respects.

As far as I see _addLink could easily add non-existing topics as outgoing links as well.

Indexing those Webxxx topics does not harm the system either besides. I'll remove them from the defaults as you supposed.

-- MichaelDaum - 24 Dec 2014

Seems to be fixed in latest release.

-- Main.MichaelDaum - 18 Sep 2017

 

ItemTemplate edit

Summary Renaming a topic results in broken links sometimes
ReportedBy LeilaPearson
Codebase 1.1.9
SVN Range
AppliesTo Extension
Component SolrPlugin
Priority Urgent
CurrentState Closed
WaitingFor
Checkins
ReleasedIn n/a
CheckinsOnBranches
trunkCheckins
masterCheckins
ItemBranchCheckins
Release02x01Checkins
Release02x00Checkins
Release01x01Checkins
Topic revision: r8 - 18 Sep 2017, MichaelDaum - This page was cached on 05 Aug 2020 - 20:37.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy