Public: Indexation issue

We have an unknown problem with the indexation. Symptoms:

• Some customers send screenshots of requirements being defined in the current AND old version of a page (i.e. “Please fix the two definitions: ‘Page title’ and \ Page title v.1'),

• Some customers report having to use the “Fix colliding keys” assistant more than once (even once is surprising),

• Some customers were unable to create a baseline when there are pages like described in point #1.

Our conclusion is that some process is creating unexpected data, and we want to investigate it thoroughly, because we are not able to reproduce in development.

We will ask willing customers to:

• Run the following SQL queries, to collect data before a problem arises,

• Whenever they meet the “colliding keys” issue or “duplicate definition” issue, use the Troubleshooting wizard in the Confluence Administration to build the Confluence Support Zip.

Note: Optionally, upgrading to 3.6.9 ensures that the UPPERKEY and KEY columns are synchronous.

4 Queries to run every day

Query 1 to list the data

As said, keep the results of those queries, and only send them to us when an error becomes visible. This first query displays the entire data, and this is important for us to understand the state of your data before any problem:

Queries 2-3-4 should return no data

Those next queries should NOT return any data. Please send the SQL data + Confluence Support Zip when one of those queries starts returning data:

When a problem arises

When you want to report a problem, such as a requirement not found, etc., please:

• 1. Collect the results of SQL queries above ;

• 2. Create the Confluence Support Zip from the Troubleshooting section of the administration.

• 3. Send it to us, through your support ticket.

Thank you!

Tips for privacy-conscious customers

IDs are not very privacy-sensitive.

If you want to have a high bar for confidentiality, here are columns that you could remove from queries, by descending order of importance:

• L.TITLE: The title of the Jira issue or associated test,

• R.KEY and R.UPPERKEY: The key of the requirement (but we need those, a lot),

• R.SPACEKEY: The key of the space of the origin page of the requirement, which could also indirectly disclose the mere existence of a space with that name (but we need those too). If you remove this spacekey, maybe it would be nice to filter by space key (WHERE SPACEKEY = 'your-space-key'),

• L.RELATIONSHIP: The name of relationship/dependencies to Jira issues.

Clues

• We think it could be environment-specific. For example, databases have a collation which is used for case-insensitive comparisons, and we suspect one of those configurations causes us to assume that a record doesn’t exist, so we create it, and it is the duplicated in the database.

• We suspect it could also be one of the other functions of our software, perhaps upgrade tasks, the rename process, the move-page process, which might create unexpected data at one point,

• It clearly doesn’t happen in development mode, nor in our quite-extensive automated tests,

• It probably isn’t a concurrency issue, because we are quite well trained on this topic, and in doubt, we’ve tried executing indexations with a few hundred threads, and they don’t create “lost records”.