Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

changesets are auto-closed 1hour after creation despite of younger edits #1816

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 7 comments

Comments

@openstreetmap-trac
Copy link

Reporter: xylome
[Submitted to the original trac issue database at 5.33am, Tuesday, 12th May 2009]

http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6 says:

  • To avoid stale open changesets a mechanism is implemented to automatically close changesets upon one of the following three conditions:
    • More than 50.000 edits on a single changeset See more specific limits
    • The changeset has been open for more than 24 hours
    • There have been no changes/API calls related to a changeset in 1 hour (i.e. idle timeout)

currently changesets are always auto-closed 1 hour after their creation.

i haven't checked the 50.000 edits limit ;-), but the 1 hour timer seems to always override the 24 hour timer.

@openstreetmap-trac
Copy link
Author

Author: tom[at]compton.nu
[Added to the original trac issue at 11.15am, Tuesday, 12th May 2009]

You haven't said what editor you are using... Potlatch did have a bug that caused it to not extend the close time when an edit was made but that should be fixed now.

Perhaps if you have the ID of a changeset that you think was wrongly handled we could have a look at it?

@openstreetmap-trac
Copy link
Author

Author: xylome
[Added to the original trac issue at 12.41pm, Tuesday, 12th May 2009]

this has nothing to do with a special client. i'm experiencing this behaviour with a bot running more than 1 hour. its opening the changeset as soon as it make its first update to an object and has to open a new changeset every hour as it gets a 409 error message. its no real problem, but there is an unecessary amount of changesets originating from the same editing session and the updates are not kept together in one changeset (which i thought was the main cause for adding changesets to api0.6)

far as i understand the api documentation in the wiki, the changeset should stay open 1 hour after the last edit of an object, just like the bounding box is expanded by every object edited (no active process by the client)

@openstreetmap-trac
Copy link
Author

Author: tom[at]compton.nu
[Added to the original trac issue at 12.45pm, Tuesday, 12th May 2009]

I asked for the ID of an example changeset so I can investigate, but apparently you don't actually want to help us find the problem, you'd rather just repeat yourself.

I have not at any point denied that there may be a problem. I have simply (in the absence of any clue as to which api methods you were using) explained about one know problem in this area that was recently fixed and asked for your help in tracking down that problem.

If you don't want to give me an example then at least tell me which API methods you are using - are you doing diff uploads or making old style calls to add/change/delete individual objects?

@openstreetmap-trac
Copy link
Author

Author: xylome
[Added to the original trac issue at 12.50pm, Tuesday, 12th May 2009]

some examples from yesterday:

http://www.openstreetmap.org/browse/changeset/1152424

http://www.openstreetmap.org/browse/changeset/1153463

http://www.openstreetmap.org/browse/changeset/1154101

only the last one is actively closed by the client

@openstreetmap-trac
Copy link
Author

Author: xylome
[Added to the original trac issue at 12.54pm, Tuesday, 12th May 2009]

the api functions used are:

  • PUT /api/0.6/changeset/create
  • PUT /api/0.6/[node|way|relation]/#id
  • PUT /api/0.6/changeset/#id/close

i'm not using the POST /api/0.6/changeset/#id/upload method.

@openstreetmap-trac
Copy link
Author

Author: tom[at]compton.nu
[Added to the original trac issue at 3.18pm, Tuesday, 12th May 2009]

Fixed in r15023.

@openstreetmap-trac
Copy link
Author

Author: xylome
[Added to the original trac issue at 2.25pm, Friday, 15th May 2009]

confirm: Fix is working

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant