Bummer - I think we handle index keys where it's the autoincremented field or even multientry where one of the entries is autoincremented. Must have missed this case.

Awesome bug, thanks! I don't suppose you want to submit a test to https://github.com/w3c/web-platform-tests ?

Also, thanks for cross-browser testing. Glad to know we're not the only one. ;-) 

I submitted a pull request for the W3C tests: https://github.com/w3c/web-platform-tests/pull/5152

Awesome!

FYI, this is non-trivial in our implementation since we inject lazily on retrieval since (1) we don't know the ID until the put operation actually runs, and (2) at that point the value is an opaque binary blob. So we have extra logic for "this index key would be a generated key, compute it at the time we are generating the ID", but it's missing the compound case.

Hopefully it's just missing logic in https://cs.chromium.org/chromium/src/content/browser/indexed_db/indexed_db_index_writer.cc?l=115

We (obviously) need more tests here. And it may require more logic in the case where the key path fails to resolve with the value that's present - we may need a "placeholder" for the compound value so that the array key is present. Dunno - anyway, awesome bug and thanks for the WPT PR!

Thanks for working on it!  Fortunately, it was really easy to just not use auto-increment in this particular instance once I figured out what the bug was.

I just noticed it works on IOS Chrome.  I'm not sure if that helps, but maybe there's some code there to look at.

iOS Chrome is a wrapper around the iOS WKWebView implementation - i.e. it's Safari's engine under the hood.

Ah... that makes sense.  That won't help then.

We briefly discussed today about the possibility of having auto-incremented primary keys assigned in the renderer. This task depends on creating a queue for outgoing requests, which would be mostly motivated by computing index keys asynchronously. If auto-incremented primary keys would be assigned in the renderer, we'd compute index keys afterwards, and this issue would be fixed.

There are lots of ifs in these statements, but I figured they're still worth recording.

Hey, is there any updates or maybe a workaround for this issue?

Currently i have to do a .add({}) followed by .put(Object.assign(obj, {id: idResultFromAdd}))

This allows me to keep the indexes updated, but i'm guessing would not be very performant when adding lots of records.

+1 We are also hitting this in our development for the Firestore Web client.

Solving this is non-trivial before onion-souping, and might be a lot easier after onion souping.

#11 - is this bug a blocker, or would you be able to live with it for a few quarters? If it's a blocker, we should bump its priority.

We worked around this issue by using the workaround described in #10. We are not currently blocked.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c9beed86261f9ca8bdda566b22f36605efc1f691

commit c9beed86261f9ca8bdda566b22f36605efc1f691
Author: Victor Costan <pwnall@chromium.org>
Date: Tue Oct 30 05:28:47 2018

IndexedDB: More WPT tests for reading from autoincrement stores.

Auto-increment keys represent a challenge in implementations where a
central browser process owns the databases' metadata, and multiple
renderer processes can access the same database.

Specifically, IndexedDB allows application code to start a transaction
and queue requests synchronously. So, there is no opportunity for the
browser process to pass the current autoincrement key to a renderer
process before the renderer processes requests. This situation can be
handled by queueing requests, which is complex, or by lazy key
injection, which looks easy and thus is quite popular, but has many
edge cases.

The tests here attempt to exercise all the code paths in lazy key
injection that work reasonably well today. The tests do not cover
compound indexes that include the primary (autoincrement) key, because
that is not handled well in any browser.

Bug: 701972
Change-Id: Ibbe38fd173d0821d329cafed449be359e2b33f6e
Reviewed-on: https://chromium-review.googlesource.com/c/1304067
Commit-Queue: Victor Costan <pwnall@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#603794}
[modify] https://crrev.com/c9beed86261f9ca8bdda566b22f36605efc1f691/third_party/WebKit/LayoutTests/external/wpt/IndexedDB/idbindex-rename-abort.html
[modify] https://crrev.com/c9beed86261f9ca8bdda566b22f36605efc1f691/third_party/WebKit/LayoutTests/external/wpt/IndexedDB/idbobjectstore-rename-abort.html
[add] https://crrev.com/c9beed86261f9ca8bdda566b22f36605efc1f691/third_party/WebKit/LayoutTests/external/wpt/IndexedDB/key-generators/reading-autoincrement-common.js
[add] https://crrev.com/c9beed86261f9ca8bdda566b22f36605efc1f691/third_party/WebKit/LayoutTests/external/wpt/IndexedDB/key-generators/reading-autoincrement-indexes-cursors.any.js
[add] https://crrev.com/c9beed86261f9ca8bdda566b22f36605efc1f691/third_party/WebKit/LayoutTests/external/wpt/IndexedDB/key-generators/reading-autoincrement-indexes.any.js
[add] https://crrev.com/c9beed86261f9ca8bdda566b22f36605efc1f691/third_party/WebKit/LayoutTests/external/wpt/IndexedDB/key-generators/reading-autoincrement-store-cursors.any.js
[add] https://crrev.com/c9beed86261f9ca8bdda566b22f36605efc1f691/third_party/WebKit/LayoutTests/external/wpt/IndexedDB/key-generators/reading-autoincrement-store.any.js
[modify] https://crrev.com/c9beed86261f9ca8bdda566b22f36605efc1f691/third_party/WebKit/LayoutTests/external/wpt/IndexedDB/support-promises.js