error when creating new registration + user tracker: tikidb.index_hash didn't exist regardless of unified search index settings (even after disabling it)

• Error
• Release Blocker

Weird issue, maybe too specific of the tiki 12 configuration for a local chapter of the World Social Forum in Catalonia.
But this is serious, and since might happen to other tikis, I report it before I forget what happened, and which manual workaround allowed us to keep going.

We have set up a Tiki site to gather information on workshops in a tracker. The Tracker (through a Wiki page with PluginTracker) also shows the registration fields, in order to get a user registered with the information of the workshop they want to propose.

That wiki page is shown through an iframe in from a wordpress (yes, this is real life; main site was created first with Wordpress, and they only want to use Tiki for the tracker system, so far).

http://www.forumsocialcatala.cat/fscat2014/inscripcio-tallers-fscat2014/

Once the form was submitted, Tiki displayed a page that an error occurred ("did you check your db is up & running", etc)
Apache logs don't show anything rellevant.
Tiki logs indicate that the database table

dbname.index_52d52c9cad158

was missing. Checking the mysql db directly, I saw that another similar db table name was there:

dbname.index_5305ecc55cd29

I did clear the Tiki caches many times, rebuild the serch index many times, changed from mysqlfts to lucene (clear caches and rebuild index each time) and back, a few times. Even disabled the unified search index. (clearing tiki caches also), and no way, each time the new item was attempted to get added to the Tiki site:

• that error page was shown
• the tiki logs showed the message that dbname.index_52d52c9cad158 was missing
• the user got added, but not the tracker item with the workshop information.

I only know that the system worked well until Feb 14th (the date of the last valid item in the tracker). After that, I svn updated to recent revisions yesterday (maybe to r49950ish or similar, I don't know for sure), and today svn-updated again, to r49974. And that mysql table either dissapeared, or was rebuilt to a different name, or the code decided to look for a different name of table at the database.

Update: I admit, that this is too of an edge case.
I have not been able to reproduce in a clone of that db in my localhost, so I close this bug report. I hope this issue doesn't happen to anyone else.

This bug has been demonstrated on show2.tiki.org

Please demonstrate your bug on show2.tiki.org

This bug has been demonstrated on show.tikiwiki.org

Please demonstrate your bug on show.tikiwiki.org