Report type:
'happened to notice it'
So, noone is going to set RTBC for needing the patch.
However, if someone ever happens to encounter this exotic problem, they will not be able to trace this => it's best off committed.

path_form_alter, for node edit forms, sets $form['path']['pid'] to remember which path alias to overwrite on submit.
It doesn't actually check whether the path belongs to the node currently being edited! So on submit, we could be overwriting (deleting) some other node's path.

On March 1st (and March 4th in Drupal 6.16), #358315 was committed, which effectively removes all constraints on the url_alias table. Now it is possible to have multiple occurrences of the same dst/language pair in the 'url_alias' table. Before this commit, it would be implicit that path_form_alter always retrieved path information for the correct node.

See #4 - #7 for the change. It seems this was done inadvertently. People added a column to a unique index for speed reasons - but failed to take into account that 'unique indexes' also double as 'constraints'. The uniqueness constraint for alias/language pairs is gone now. least, this removing of the constraint seems inadvertent, because it is not discussed anywhere. (Not in #358315 anyway.)

Mitigating factors:
- the node edit form. and pathauto_create_alias(), both check for an existing alias in the url_alias table. So the only way for a duplicate dst/language pair to end up in the 'url_alias' table, is for contrib code to call path_set_alias() with an 'alias' argument that already exists for another 'path'. Or to change $node->path to an existing node's path and then call node_save().
- drupal_lookup_path() always sorts by 'pid DESC' when looking up paths/aliases, so duplicate aliases in the 'url_alias' table do not cause unpredictable behavior. (Note that this did introduce a behavior change in D6.16: in D6.15 if a node tries to register a duplicate path alias, this will generate an SQL error - and in D6.16, the node will silently become the 'effective owner' of the alias.)

This is why I doubt whether regarding the absence of the constraint should be considered a bug in itself. I don't feel qualified to judge this (and it's too much work :p) - feel free to take this up elsewhere.

Why reported for D6:
In D7, path_form_node_form_alter() retrieves the path information by 'src' (source path), instead of by 'dst' (alias). So the problem doesn't exist there.

( system_update_6055 dst_language dst_language_pid <- keywords for search engines :) )

#6 path-nodeform-pid-1106030-2_D6.patch663 bytesroderik
#2 path-nodeform-pid-1106030-2.patch663 bytesroderik
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch path-nodeform-pid-1106030-2.patch.
[ View ]
path-nodeform-pid.patch671 bytesroderik
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch path-nodeform-pid.patch.
[ View ]


Status:Needs review» Needs work

The last submitted patch, path-nodeform-pid.patch, failed testing.

new663 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch path-nodeform-pid-1106030-2.patch.
[ View ]

First time git user. Git instructions do not mention to use '--no-prefix' (ok, I should have figured...)

Status:Needs work» Needs review

way to keep myself occupied...

Status:Needs review» Needs work

The last submitted patch, path-nodeform-pid-1106030-2.patch, failed testing.

Status:Needs work» Needs review
new663 bytes


It seems the first patch should have been able to satisfy the testing bot anyway. (Above patches are the same except the original applies with -p1.)
The test details don't give any clue.

So shut up testing bot. Here.