Skip to content
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

Attaching files post-initialization #18

Open
cjserio opened this issue Sep 13, 2022 · 2 comments
Open

Attaching files post-initialization #18

cjserio opened this issue Sep 13, 2022 · 2 comments

Comments

@cjserio
Copy link

cjserio commented Sep 13, 2022

We've got a bit of an issue and I can only think of bad solutions so I'm hoping I've just overlooked something obvious. We're using the "attachments" argument to 'StartHandler' to attach our log file on a crash. This works great. The log file is always there on disk...it's always useful to us...and it's uploaded successfully every time.

The issue is that there are often needs to add MORE files at a later time....files that did not exist at the time the handler was started and whose name/location might not be predictable early either. These are non-fatal incidents where the process is still healthy. (A GPU error for example). We cannot find a way to add files later.

Some ideas that I considered:

  1. Killing the existing handler and starting a NEW handler now that we have more specific file location information. There seems to be no exposed way to kill/restart a handler though.
  2. Communicating with the handler to send more information via IPC. This would require customizing the handler source of course which isn't ideal.
  3. Disable 'Uploads', write ourselves a private note somewhere to disk about the location/need of the extra files and then add them to the report the next time the app is restarted and THEN upload it. It seems like the only access to a 'Report' implies that its immutable and cannot easily add attachments to it.
  4. Let the system upload reports without the extra attached files and then upload them directly to backtrace later. I've not found an API for this but maybe there's some URL we can use to send via CURL on a worker thread if we knew the report's UUID.
  5. Add one or more placeholder paths to StartHandler. If we end up needing them later, we can rename the files to align with those paths. If we don't end up needing them, it seems like handler doesn't care that the files don't exist and will just log out an error but still continue just fine. This seems like it would work but it's a bit crude.

Would you guys have any recommendations on this issue?

Thanks!

@cjserio
Copy link
Author

cjserio commented Sep 29, 2022

It seems like if we don't allow automatic uploads, we can simply put more files in the proper crash UUID's 'attachments' folder and they get uploaded auto-magically. This is a useful side-effect though the issue becomes knowing the UUID of the crash so we know where to move the attachment to the next time the app is run. I guess we can just got by the date/time stamps on the DMP and other files but I was hoping for a more reliable way.

I'd also love the ability to add more attributes post-crash. Users want to include notes about what they were doing at the time of the crash to help us as well as provide their information so we can contact them. I see no way of doing that without manually opening up the minidump and writing it directly. Perhaps we're just really petting the cat backwards with all of these intentions?

@vlussenburg
Copy link
Contributor

vlussenburg commented Oct 24, 2022

Add one or more placeholder paths to StartHandler. If we end up needing them later, we can rename the files to align with those paths. If we don't end up needing them, it seems like handler doesn't care that the files don't exist and will just log out an error but still continue just fine. This seems like it would work but it's a bit crude.

Classically, this is what I've seen being used. It's even possible to create symlinks on the fly and have generic crashattachment_N attachment paths provided on startup. It's not very pretty, but it works.

Having said that, in the future, we could look at improving this.

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

No branches or pull requests

2 participants