Skip to content

rollback! is inefficient #5

@julik

Description

@julik

At the moment when we rollback we need to rebuild the PathSet from the start (because we do not know which entry contributed which paths). In a degenerative case where entry 900 gets retried over and over it will re-build the path set with 900 paths, on every retry. Ideally this could be done better with a dependency graph. The @files and the PathSet could then be combined into something like EntrySet in rubyzip which would take care of this. We could also add the last element as a "rollbackable" - because once the Streamer moves past it is not necessary to roll it back. That way the checks would be against previous_to_last_state + last_item_state_change, not just against last_state

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions