sasikala Reporter
	Description • 10 years ago

1. Title : DB exceptions in applications when 'Application storage' is full
2. Precondition: Application Storage should be full
3. Tester's Action: 
   case a) Gallery app:
            1.Open Gallery application
            2.No images are shown and scanning is not happening
      Error: can't open database: UnknownError

   case b) SMS application
            1. Open SMS application
            2. Enter number and text -> select back key
            3. Save as draft
            4. Kill the application/restart the device -> 
            5. Draft messages are  not shown
       Error: asyncStorage: can't open database: UnknownError

    case c) Video app
             1. Open video app
             2. Not listing any video files & scanning is not happening
       Error: MediaDB(): UnknownError
    
    case d) music app
             1. Open music application
             2. Not listing any music files & scanning is not happening
       Error: asyncStorage: can't open database: UnknownError

    case e) contacts app
            1. Open contact application
            2. Create and save new contact
       Error: Error saving contact QuotaExceededError

	Veeresh
	Comment 1 • 10 years ago

wayne,

WIll you please get right people to look in to this?

	Wayne Chang [:wchang]
	Comment 2 • 10 years ago

Keven, Thomas,

I think this is expected but can you take a look and have someone follow up?

	Evelyn Hung
	Comment 3 • 10 years ago

There is no way to stop user running out his/her storage, so I think it's fine as long as we provide a proper warning while the storage reaches a high usage level.

@Gary, could you help check is there any application that catch the notification from "device-storage:apps" API and display a warning? Thanks.

	GaryChen [:GaryChen][:PYChen][:gchen][:陳柏宇]
	Comment 4 • 10 years ago

Okay, I'll take a look.
Keep "ni" flag for tracking.

	GaryChen [:GaryChen][:PYChen][:gchen][:陳柏宇]
	Comment 5 • 10 years ago

Hi all,
   I found there is a |storage_watcher| in system app, it would take responsibility to monitor |device-storage:apps| status.
   It means system app should prompt warning dialog while the storage occurs |low-disk-space| event.

V1.4:
https://github.com/mozilla-b2g/gaia/blob/v1.4/apps/system/js/storage_watcher.js
Master:
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/storage_watcher.js

	Sharaf
	Comment 6 • 10 years ago

I believe that this is a blanket event which monitors "/data" partition usage. 
When we are in low space situation we are able to see the warning message, but it’s not at all any use to the end user. 

During low space situation internal applications are not at all working as expected,

* We can’t delete any data (mainly IndexDB related)
* We can’t change any settings
* There is no feedback from any of the pre-loaded application for failed operations due to low space (e.g. Contact add or delete)
* Also, we can’t selectively clear data used by any unwanted application.

We should ensure that the internal application works as expected during low space situations, or at least end user should be informed about the failed operations.

Also it should be possible for the user to get out of the low space scenario by clearing application private data.

ni? to Evelyn for comments

	Evelyn Hung
	Comment 7 • 10 years ago

(In reply to Sharaf from comment #6)
> 
> I believe that this is a blanket event which monitors "/data" partition
> usage. 
> When we are in low space situation we are able to see the warning message,
> but it’s not at all any use to the end user. 
> 
> During low space situation internal applications are not at all working as
> expected,
> 
> * We can’t delete any data (mainly IndexDB related)
> * We can’t change any settings
> * There is no feedback from any of the pre-loaded application for failed
> operations due to low space (e.g. Contact add or delete)
> * Also, we can’t selectively clear data used by any unwanted application.
> 
> We should ensure that the internal application works as expected during low
> space situations, or at least end user should be informed about the failed
> operations.
> 
> Also it should be possible for the user to get out of the low space scenario
> by clearing application private data.
> 
> ni? to Evelyn for comments

Yes, I agree you. ni product guy to take this bug into backlog so it can be considered seriously in our future release.

	Evelyn Hung
	Comment 10 • 9 years ago

Hema and David, need your help here. Also copied my comment on bug 1177038 below:

> Clarify the problem I observed: user data ran out all data space so
> application can't write anything into its Indexed DB, and then application
> can't work as normal.
> 
> Here are questions come to my mind:
> 
> (...)
>  
> 2. IndexedDB accessing failure shouldn't affect UI displaying video list. It
> seems that we didn't handle this case well. Hema, could you find someone
> from Media team to identify if this is something about error handling?

I'd like to know why IndexedDB failure blocks UI in this case.

	David Flanagan [:djf]
	Comment 11 • 9 years ago

I'm leaving for vacation, and don't have time to investigate this myself right now.  From the errors reported last year in comment #0, it sounds like the error is that we can't even open the database at all. Media apps store all their data in the db, so if we can't open the db, then we can't display any UI. That is a hard failure.

Maybe we need a change to IndexedDB where opening a db and doing read-only transactions are allowed when we're out of space but readwrite transactions fail.

I'm guessing there isn't anything we can do about this in Gaia. It is too bad that today is Ben Turner's last day because he would otherwise be a good person to needinfo.

How are testers filling up their application data when testing this bug? Are they just installing lots of apps? Maybe we can modify the system app or gecko to not allow an app to be installed if it would make the partition more than 90% full.  That plus a warning dialog when it gets too high might be enough.

	Hema Koka [:hema]
	Comment 12 • 9 years ago

Adding dhylands for his input

	Dave Hylands [:dhylands]
	Comment 13 • 9 years ago

My understanding is that when the data partition goes below some amount (a few Mb) then all IndexedDB writes will start to fail.

This is by design.

By keeping a very small buffer, it allows IndexedDB to maintain the integrity of the data that it does have.

If we set the limit to zero, then you can no longer ensure that the database integrity is preserved.

Apps are expected to deal with this gracefully and should consider this as /data is full.

	BMO Automation
	Comment 14 • 6 years ago

Firefox OS is not being worked on