-
Notifications
You must be signed in to change notification settings - Fork 100
Fix: release watched files on completion (in read-mode) #271
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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