-
Notifications
You must be signed in to change notification settings - Fork 207
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
Filestore thread safety fixes #295
Conversation
moves code to delete files to single method within filestore
acquire a lock when writing/deleting files directly from the filestore
only deletes stored files if they are not already queued for a request
Pull Request Test Coverage Report for Build 1331
💛 - Coveralls |
1 similar comment
Pull Request Test Coverage Report for Build 1331
💛 - Coveralls |
adds tests for basic functionality of newly added methods
iterate through files and delete unqueued files if the max storage limit is reached
initialises a filestore directly in unit tests, rather than relying on the client. this should reduce side effects (e.g. error flushing on launch) which may have led to flakiness
provide a null check in the unlikely case the collection param is null
@bugsnag/platforms this is now ready for review. |
@@ -82,26 +100,63 @@ String write(@NonNull T streamable) { | |||
filename), exception); | |||
} finally { | |||
IOUtils.closeQuietly(out); | |||
lock.unlock(); |
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.
Is there a chance this can fail if IOUtils throws?
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.
NVM, I just looked up what IOUtils.closeQuietly
does
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, but I'm not overly familiar with either Java or this notifier so @Pezzah would you be able to get a look in?
} | ||
return null; | ||
} | ||
|
||
@NonNull abstract String getFilename(T streamable); | ||
@NonNull | ||
abstract String getFilename(T streamable); | ||
|
||
List<File> findStoredFiles() { |
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.
I think this can be called multiple times in the current design, which might cause bad things to happen. Potentially this should only return files that are not already in the queued files set?
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.
Good point. I've updated this method so that it only returns stored files which aren't in the queuedFiles
collection.
finding stored files in filestore should now only return files which are not currently enqueued. this prevents bad things happening if a delivery client looks up files twice for example, and attempts to send duplicate reports.
Fix bugsnag.sharedObjectPaths not uploading SO files
…r-uplifts bugsnag-unity v5.0.0
We sometimes receive invalid payloads with an empty/malformed array where an error/session should be - e.g.
[]
or[,]
. My hypothesis is that this occurs when the max limit of Error/Sessions are cached on disk. When the app is relaunched, ifwrite
is called just before the payload is serialised, then this can lead to the oldest File being deleted, which means there is no data to serialise.This attempts to address this scenario by retaining a reference to any Files which are currently being flushed, and not deleting them.
A potential downside to this implementation is that it currently requires manually calling
cancelQueuedFiles
anddeleteStoredFiles
, which could be forgotten.