-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Fix: release watched files on completion (in read-mode) #271
Fix: release watched files on completion (in read-mode) #271
Conversation
4bf6de5
to
9a0ca2b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general LGTM, only a couple of questions
end | ||
@sort_method.call | ||
removed_files |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not clear to me why we the remove_paths
returns the list of removed files. The method remove_paths
is used inside the DeleteCompletedFileHandler.handle
which on its own return the list of deleted files. That method is invoked by File.handle_deletable_path
in an each loop and the method itself doesn't return nothing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Andrea, might have been a bit ahead of myself here ...
It's common for a (map) remove operation to return removed values.
The watched files collection is a ~ map ([String] path -> [WatchedFile] file
), wanted to re-turn smt meaningful (planning to spec the return value with a collection rewrite to native).
0cef200
to
59bb43e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
59bb43e
to
309cdd8
Compare
not doing so leads to a steady increase in watched collection's size over time (esp. in use-cases where user is pulling in new files). the left-over file is never to be processed again - it's being deleted anyway using the completion handler.
not doing so leads to a steady increase in watched collection's size
over time (esp. in use-cases where user is pulling in new files).
the left-over watched file entry is never to be processed again - it's being deleted anyway (assuming
'file_completed_action' => "delete"
) using the completion handler.resolves #270
NOTE: please ignore the existing potential atomicity issues in the watched file collection a follow-up on this PR will deal with a
WatchedFileCollection
rewrite