Content-Hub crash with an invalid app-id after transfer and doesn't clean up temp files

[Didier Roche-Tolomelli]

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.

[Ken VanDine (ken-vandine)]

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.

[Didier Roche-Tolomelli (didrocks)]

The service is crashing, and thus, that's why the files are never cleaned up properly.

[Sebastien Bacher (seb128)]

is that the same issue than bug #1472026? Do you have a stacktrace of the issue? does it hit a gsettings abort there?

[Didier Roche-Tolomelli (didrocks)]

Doesn't seem to be the same issue. You can see it reported here: https://errors.ubuntu.com/oops/1d05fc26-4264-11e5-bfa6-fa163e4aaad4