Re: [whatwg/fetch] Deferred fetching (PR #1647)

@mingyc commented on this pull request.



> +   optimize batching of deferred fetches.
+
+   <li><p>If the result of atomically exchanging the value of <var>deferredRecord</var>'s
+   <a for="deferred fetch record">invoke state</a> with "<code>sent</code>" is
+   "<code>scheduled</code>", then <a for=/>fetch</a> <var>record</var>'s
+   <a for="fetch record">request</a>.
+  </ol>
+ </li>
+</ol>
+
+<p>When a <a for=fetch>fetch group</a> <var>fetchGroup</var> is
+<dfn export for="fetch group" id=concept-fetch-group-reactivate>reactivated</dfn>:
+<a for=list>For each</a> <a for=/>deferred fetch record</a> <var>deferredRecord</var> in
+<var>fetchGroup</var>'s <a for="fetch group">deferred fetch records</a>: If the result of atomically
+exchanging the value of <var>deferredRecord</var>'s <a for="deferred fetch record">invoke state</a>
+with "<code>deferred</code>" is "<code>sent</code>", then <a for=list>remove</a>

> If we did this in deactivated, there would be a short window where the fetch record is still in the list even though it's committed, which means it would, for example, affect the deferred fetch quota.

Could you please help me understand why removing record in `deactivated` will still affect the quota? Couldn't `totalScheduledDeferredBytesForOrigin` also be updated in `deactivated`?

I am fine with the current approach if updating introduces unexpected behaviors. The fact that script cannot be executed in between (bfcached document) makes moving this step into `deactivated` help nothing in terms of quota.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1647#discussion_r1247665079
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/pull/1647/review/1506863334@github.com>