Bug 282093 – IndexedDB breaks randomly | UnknownError: Error looking up record in object store by key range

• Component: Website Storage
• Status: NEW

[Mark Langer]

Created attachment 473040 [details]
Diagnostics Report MacOS - MacBook Apple Silicon

Every week, our users
* get errors writing or reading from IndexedDB.
* binary files inside IndexedDB are mixed up (the key with which an image file is stored returns a different image when reading it.)

This happens only on Apple devices and only with Safari. Hence, we can rule out own code errors.

Seen on:
* MacBook Pro (Apple Silicon)
* iPhones (iOS 17.4 and 18.0.1 - non-exhaustive list)
* iPads (iPadOS 17.4 and 18.0.1 - non-exhaustive list)

Error Messages include:
* UnknownError: Error looking up record in object store by key range
* AbortError
* Cannot open cursor to perform index gets in database (may be emitted by idb by Jake Archibald)

Short term solution:
* Quit Safari. Closing the window or opening a new tab doesn't help. Assumption: Some background service(s) is/are breaking.

Today, we saw a diagnostics report on a MacBook on com.apple.WebKit.WebContent happening while the error was reproducible.
Content: CPU above 50% for over 90 seconds.

Thought: There might be a threshold on Macs killing processes if they use too much CPU for too long?

Attachments:
* Diagnostics Report
* Console Logs Safari

[Mark Langer]

Created attachment 473041 [details]
Console Logs Safari - MacBook Pro Apple Silicon

Attachment 2:

[Mark Langer]

Possibly related, yet not resolved:

https://bugs.webkit.org/show_bug.cgi?id=277615
https://bugs.webkit.org/show_bug.cgi?id=273827
https://bugs.webkit.org/show_bug.cgi?id=197050

[Mark Langer]

Today we had another incident with mixed up photo files from IndexedDB.

The diagnostics reports showed two dubious events:

1) -----------
com.apple.WebKit.Networking
Event:            disk writes
Action taken:     none
Writes:           2147.50 MB of file backed memory dirtied over 33710 seconds (63.71 KB per second average), exceeding limit of 24.86 KB per second over 86400 seconds
Writes limit:     2147.48 MB
Limit duration:   86400s
Writes caused:    2147.50 MB


2) -----------
com.apple.WebKit.WebContent
Event:            cpu usage
Action taken:     none
CPU:              90 seconds cpu time over 145 seconds (62% cpu average), exceeding limit of 50% cpu over 180 seconds
CPU limit:        90s
Limit duration:   180s
CPU used:         90s
CPU duration:     145s

--------------

Quitting Safari and restarting it usually resolves the issue for a while.

[Mark Langer]

Created attachment 473062 [details]
WebKit Networking Diagnostic Log

[Mark Langer]

Created attachment 473063 [details]
WebKit WebContent Diagnostic Log

[Mark Langer]

Created attachment 473079 [details]
WebKit WebContent Diagnostic Log

Today, we whitnessed the shuffling again with another customer on MacOS 15.0.1.

WebContent caused a diagnostic log again.

[Radar WebKit Bug Importer]

<rdar://problem/139068307>

[Mark Langer]

Hi Apple team! Are there any updates on this?

The issue is still happening in the same ways as described above.

The issue is still unassigned. Is there a brave engineer wanting to tackle this? 🦸🏼‍♂️🦸🏽‍♀️

[Mark Langer]

Dear Apple team,

I'd like to bring this bug to your attention again. I'm afraid it breaks the displayed data for people using binary files from IndexedDB, therefore the classification major severity. Is there anything you guys can do?

Currently, nobody is assigned. Could that be the first step to begin with?

Best,
Mark

[Lincoln Baxter, III]

We are still seeing this on the most recent iOS. Please help!

[Mark Langer]

I've updated the priority to P1 / Critical because we're still seeing random data storage breaking in production.

@Apple: Isn't there anyone in Cupertino who is able and willing to tackle this issue? We've added multiple pieces of documentation that could help with debugging.

(In reply to Mark Langer from comment #11)
> I've updated the priority to P1 / Critical because we're still seeing random
> data storage breaking in production.

Could you perhaps add <https://bugs.webkit.org/show_bug.cgi?id=277615>
to See Also? It seems likely these are related (or the same), and that bug
has more comments.