Opened 10 years ago

Closed 7 years ago

#1736 closed defect (fixed)

Cannot edit relation, 412 Precondition Failed

Reported by: Candid Dauth Owned by: tom@…
Priority: minor Milestone:
Component: api Version:
Keywords: api0.6 Cc:

Description

I am trying to change the tags of relation 30431. (In detail, at the moment I am trying to set the name to “Rhein-Route (CH)”.) Both with JOSM and Merkaartor, I always receive a 412 Precondition Failed error, no matter what I try. It can’t be the case that one of the members of the relation is deleted while I am editing it as I’ve tried so many times now and let only one minute pass between downloading and uploading.

This is the only relation that this happened to me with, other relations where editable without problems.

Change History (12)

comment:1 Changed 10 years ago by Candid Dauth

  • Priority changed from major to critical

comment:2 follow-up: Changed 10 years ago by tom@…

  • Priority changed from critical to minor

comment:3 in reply to: ↑ 2 Changed 10 years ago by Candid Dauth

Replying to tom@compton.nu:
Don’t you think that parts of the database being read-only is a bit more important than “minor”?

comment:4 Changed 10 years ago by tom@…

Not when it's one object out of tens of millions, no. It's certainly not critical, which is what you tried to bump it up to - that would be something that left the whole site unusable.

comment:5 Changed 10 years ago by ed@…

It's not just one relation though. See for example relation 15020. Now you've fixed the data browser issue which showed the sequence numbers, I can't still see that the first item in the sequence is 124000 and something, but I suspect this is a migration bug which has affected a number of relations. In my case I've not tried changing tags, but have tried adding or deleting ways and both fail with Precondition failed (in both JOSM and Potlatch). I don't know what precondition is failing, but are sequence ids > 65535 valid in the checks? I would classify this as major until the extent can be determined (and I guess that needs to be done by someone who can work out what the precondition that is failing is, and whether it is indeed sequence if related).

comment:6 Changed 10 years ago by Candid Dauth

I’ve checked every way that is a member of the relation 30431 and every node that is a member of one of those ways, all of them definitely exist and are visible (I received them in two calls using http://openstreetmap.org/api/0.6/ways and /nodes).

Looking at relation 15020, I see that both relation 15020 and 30431 have had multiple versions committed in the last changeset. As for all other relation I have edited this was not the case, maybe this is related to the bug? (I have no idea how usual it is to commit multiple versions in one changeset.)

By the way, of course this bug is not “critical”, but in my opinion it is more important than many of the bugs classified as “major” (which should be “minor” in my opinion).

comment:7 Changed 10 years ago by grand.edgemaster@…

Once #1783 is fixed, we should be able to see which component member is causing the breakage.

comment:8 Changed 10 years ago by grand.edgemaster@…

#1783 is fixed, I tried the edit as requested, the API is now returning the _very_ helpful error:

POST http://www.openstreetmap.org/api/0.6/changeset/1112373/upload... Precondition Failed
Error body: Precondition failed: Cannot update relation 30431: data or member data is invalid.

Looks like we're going to need to make them more specific...

comment:9 Changed 10 years ago by ed@…

Relation 15020 is now fixed. The newly helpful error messages in JOSM told me which way was causing a problem. Using /browse/way/<id> showed that this way was deleted. I tried removing it from the relation in JOSM and uploading but this gave error 500, so next used Potlatch to undelete the way, remove it from the relation, and delete the way again. This fixed relation 15020. I am about to see if I can do similar with 30431, although not knowing the area so well may make it trickier.

comment:10 Changed 10 years ago by grand.edgemaster@…

When getting 500s, it'd be VERY useful to also have the changeset id, so the source of it can be traced back. Ideally, the server should not return any 500s.

comment:11 Changed 10 years ago by ed@…

I'll know next time. This relation is fixed. One way contained some deleted nodes. Sufficient fiddling with the way in Potlatch somehow undeleted them, and I updated the name using JOSM as a test. So I suspect this ticket can be closed, although there may well still be ways containing deleted nodes, or deleted ways, that are part of other relations and each of these will need fixing as they are encountered.

comment:12 Changed 7 years ago by TomH

  • Resolution set to fixed
  • Status changed from new to closed

It sounds like this is effectively fixed now as the error messages now provide all the details needed to resolve any problems.

Note: See TracTickets for help on using tickets.