I have two Kanboard 1.2.7 instances and on both, internal links seem to behave unpredictably.
I can’t sometimes can’t create tasks with “blocks” or “is child of”, the error is something like “this exact same link exists already”, but that isn’t true. The error also sometimes appears between two freshly created cards with no links at all.
On the other hand, when I can create a link the matching other side of the link either doesn’t get created or may be wrong. For example, I create card A that “is child of” task B. But on task B, task A does not appear at all.
Am I misunderstanding how this is supposed to work? I haven’t been able to find a pattern for when it works and when it doesn’t.
Thanks for the instance. The problem doesn’t seem to happen there. But I’ve installed our Kanboard test instance fresh from 1.2.6 and then upgraded to 1.2.7. It always had this problem and I expected 1.2.7 to solve it. Any idea what it could be? Unfortunately, I can’t give you an account on our instance since it’s only reachable from inside our network.
With debug disabled, nothing is logged. So I enabled debug and put a debug.log (anonymized) and config.php (slightly redacted) here. What you see is that I:
Try to delete an existing “blocks” connection between tasks 35 and 37. In the UI, I get the error “Unable to remove this link.”
Try to add a “blocks” relationship between tasks 35 and 39. This works, but on both sides the link is marked as “blocks”, but on task 39 it should be “is blocked by” towards 35.
I was also able to trigger the “the exact same link already exists” error between two tasks that have no links at all, but unfortunately debug mode was off at the time.
No real errors seem to be logged and I don’t see anything useful in that SQL. Do you?
By configuration, I meant:
Configuration
Application version: 1.2.7
PHP version: 7.2.13
PHP SAPI: fpm-fcgi
OS version: Linux 4.9.45-rancher
Database driver: sqlite
Database version: 3.24.0
Browser: Mozilla/5.0 (iPad; CPU OS 11_4 like Mac OS X) AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/71.0.3578.89 Mobile/15E148 Safari/604.1
I’ll try and spin up a similar container and see if I can replicate.
Couple things you can do to rule out suspects.
Uninstall Milestone plugin, doubtful, but worth a try.
Switch to Sqlite, just to rule out MariaDB. I’ve never used kanboard with Maria, I doubt it’s the culprit, but might as well rule it out too. When you switch to Sqlite, you’ll loose all your data, but you can switch back to Maria and it will all come back, back up your files though, just incase.
Thanks, I will go through that in the coming week. We have staging infrastructure and backups so I can also try any destructive things that might be necessary.
I’ve done something else first: Tried it on a VM with PHP 7.2. The problem does not appear there. Now I have to test if it’s only an issue on PHP 7.0. Edit: Doesn’t seem to be a problem as long as it’s a fresh install of 1.2.8. A fresh 1.2.8 on either PHP 7.0 or 7.2 using an empty sqlite database also works. So perhaps it’s a data issue.
I’m not sure what version this Kanboard was when we started, maybe some migration went wrong and caused this?
I may have a lead. Is it possible that Kanboard is unable to deal with auto-increments if they are not increments of 1? One can never know what kinds of increments a database server might use, and in this case, it’s an increment of 2. This appears to mess up the links table?
On the non-working instance, we have this, the opposites don’t match up:
+----+-------------------+-------------+
| id | label | opposite_id |
+----+-------------------+-------------+
| 1 | relates to | 0 |
| 3 | blocks | 3 |
| 5 | is blocked by | 2 |
| 7 | duplicates | 5 |
| 9 | is duplicated by | 4 |
| 11 | is a child of | 7 |
| 13 | is a parent of | 6 |
| 15 | targets milestone | 9 |
| 17 | is a milestone of | 8 |
| 19 | fixes | 11 |
| 21 | is fixed by | 10 |
+----+-------------------+-------------+
On the working instance which uses a different MariaDB server, we have this:
+----+-------------------+-------------+
| id | label | opposite_id |
+----+-------------------+-------------+
| 1 | relates to | 0 |
| 2 | blocks | 3 |
| 3 | is blocked by | 2 |
| 4 | duplicates | 5 |
| 5 | is duplicated by | 4 |
| 6 | is a child of | 7 |
| 7 | is a parent of | 6 |
| 8 | targets milestone | 9 |
| 9 | is a milestone of | 8 |
| 10 | fixes | 11 |
| 11 | is fixed by | 10 |
+----+-------------------+-------------+
Yeah, I linked to that in the issue. That’ll have to change, most clusters use increments != 1. In the schema, Insertion of a label should catch the ID assigned to it and use it as opposite_id for the insertion of the next one.
We are trying to put together some SQL queries that can fix the data now for those tasks that point to the wrong labels, but it would be good to also have this in a migration inside of Kanboard so other instances that use MySQL clusters would be fixed as well.
I’ve submitted a pull request that fixes it and attached it to the issue on GitHub. Tested it on a cluster with 4 members and one with 2. auto_increment_increment was set to 4 and 2, respectively.
Yes, that’s true. But at least new installations would work. I didn’t want to change existing data in case someone has figured out the IDs are wrong and has fixed them via the admin panel. But on the other hand, doing it by hand should lead to the same opposite_id as I get from the database, so I guess I could do it in a new migration.
Should I leave version_46 as it is now, with dynamic IDs, or revert it to the hardcoded IDs?
I’m sure Fred will respond to the pull request, but I’m 100% positive you shouldn’t be touching version_46 or old version_ functions, it would have to be in a new version_