Content-Hub crash with an invalid app-id after transfer and doesn't clean up temp files
Bug #1483558 reported by
Didier Roche-Tolomelli
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
content-hub (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
The idea would to have at least a fake APP_ID for developping and testing/iterating on desktop. The import functionality itself works, but the crash doesn't give a good developer experience.
Maybe we can decide on having an APP_ID=fake in the developer default template, and then, content-hub let that ID pass even if not installed?
Note that one of the side effect of this crash after transfer is that the tmeporary files under HubIncoming aren't cleaned up.
summary: |
- Content-Hub crash with an invalid app-id + Content-Hub crash with an invalid app-id after transfer and doesn't + clean up temp files |
description: | updated |
no longer affects: | content-hub (Ubuntu) |
affects: | content-hub → content-hub (Ubuntu) |
To post a comment you must log in.
Is it the content-hub-service that crashes? Or the app? If the service doesn't crash, the cached file should still get cleaned up with the service exits.
The problem with APP_ID=fake is we need the APP_ID to be parse-able by libubuntu- app-launch, plus it needs to be unique. I wish setting applicationName in the MainView would be enough to set the runtime APP_ID, but it isn't.