Add `race-network-and-fetch-handler` option #10

sisidovski · 2024-02-05T05:26:28Z

This PR will add the spec explanation for the race-network-and-fetch-handler source in the static routing API.

This option starts the race between the network request and the fetch handler execution, and use the result whichever comes first. Currently the result from the network request is used only when the the response is successfully returned.

Borrowed sentences mostly from the navigation preload.

Preview | Diff

sisidovski · 2024-02-05T05:35:43Z

@yoshisatoyanagisawa @domenic Could you take a look? As this is the first draft, I'm not confident with how to describe the parallelism on this option, and want to know what's missing.

docs/index.bs

sisidovski · 2024-02-06T07:59:35Z

Updated to address review points and some concerns.
Main diff:

Fixed not to return |response| twice on Handle Fetch, by splitting Handle Fetch and call the latter part with in parallel, and manage the race with queue.
If race-network-and-fetch-handler source is used, do not dispatch navigation preload.

Note: In the race, the response from the network request is queued only when the result is successful (currently 200). On the other hand, the fetch handler response is queued regardless of the result.

docs/index.bs

yoshisatoyanagisawa · 2024-02-06T10:37:02Z

Other than my minor comments, the PR looks good to me.

sisidovski · 2024-02-06T15:31:01Z

@domenic Could you take a look? Thanks!

docs/index.bs

domenic · 2024-02-07T06:39:22Z

Some of the in-parallel stuff you're running into here is a preexisting issue with the spec, it seems. I filed whatwg/fetch#1734. I think my above advice helps avoid making the existing problem worse and so is still worth following.

…00 to [=ok status=], updated the caller for fetch |reqeuest|

Reflecting the comment on yoshisatoyanagisawa/ServiceWorker#10 (comment) Bug: 1371756 Change-Id: I6de1fed384e32fbdae40799ef48d4ce2eeb3eccd

Reflecting the comment on yoshisatoyanagisawa/ServiceWorker#10 (comment) Bug: 1371756 Change-Id: I6de1fed384e32fbdae40799ef48d4ce2eeb3eccd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5276401 Reviewed-by: Minoru Chikamune <[email protected]> Reviewed-by: Yoshisato Yanagisawa <[email protected]> Reviewed-by: Kouhei Ueno <[email protected]> Commit-Queue: Shunya Shishido <[email protected]> Cr-Commit-Position: refs/heads/main@{#1257762}

docs/index.bs

domenic · 2024-02-09T03:54:22Z

docs/index.bs

-      1. If |request| is a <a>non-subresource request</a>, |request| is a [=navigation request=], |registration|'s [=navigation preload enabled flag=] is set, |request|'s [=request/method=] is \`<code>GET</code>\`, |registration|'s [=active worker=]'s [=set of event types to handle=] [=set/contains=] <code>fetch</code>, and |registration|'s [=active worker=]'s [=all fetch listeners are empty flag=] is not set then:
+          1. Else if |source| is {{RouterSourceEnum/"race-network-and-fetch-handler"}}, and |request|'s [=request/method=] is \`<code>GET</code>\` then:
+
+              Note: In order to avoid duplicated fetches to |request|, the user agent may reuse |raceNetworkRequestResponse| as the result of {{FetchEvent}}'s [=FetchEvent/potential response=], or the fallback request.


This seems like it's specifying a possibly significant and observable step, via a vague non-normative note. Am I understanding correctly?

It seems to me you need to have some place to store the raceNetworkRequestResponse, modify all the call sites that set the potential response, instead.

Yes, your understanding is correct. Let me try writing this behavior in a spec level.

Updated a bit to capture the case when the user agent reuses the network response for the fallback.

The other part is more problematic.

the user agent may reuse |raceNetworkRequestResponse| as the result of {{FetchEvent}}'s [=FetchEvent/potential response=]

Actually this sentense was wrong. We have a dedupe mechanism for the |request| level, that means if fetch(e.request) is called inside the fetch handler, the user agent reuse the response dispatched before. But the response of fetch(e.request) is not [=FetchEvent/potential response=]. Partial response basically means the returned value in e.respondWith(), which may use fetch(e.request) response internally, but that's usually differnt data'.

I'm not sure how I can write this behavior in the spec, any advice would be appreciated.

It sounds like you'd need to add quite a bit of spec machinery here, to parallel the implementation machinery. Probably that would involve a PR to https://fetch.spec.whatwg.org/ to modify the behavior of fetch(), or maybe one of the underlying algorithms like main fetch or HTTP-network fetch. And some sort of side table tracking the request -> response that can be used to short circuit the normal fetching, etc.

Basically, how did you implement this in Chromium? You'll need to write up equivalent spec text.

Updated, diff from the last patch is:

Added request/service-workers race token and set it when the race network request is created.

Added race response map in ServiceWorkerGlobalScope. The map takes a token string as a key, and a promise that will be resolved with the response as a value.

Added Lookup Race Response. That returns the promise if there is an entry in the map, otherwise null. That will be called from Main fetch in the fetch spec.

I also updated the fetch spec.

Added >service-workers race token as an associated property of request.

Added the logic to return response early if there is a corresponding entry with the token string.

…t response, a=testonly Automatic update from web-platform-tests Use OK status to check RaceNetworkRequest response Reflecting the comment on yoshisatoyanagisawa/ServiceWorker#10 (comment) Bug: 1371756 Change-Id: I6de1fed384e32fbdae40799ef48d4ce2eeb3eccd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5276401 Reviewed-by: Minoru Chikamune <[email protected]> Reviewed-by: Yoshisato Yanagisawa <[email protected]> Reviewed-by: Kouhei Ueno <[email protected]> Commit-Queue: Shunya Shishido <[email protected]> Cr-Commit-Position: refs/heads/main@{#1257762} -- wpt-commits: 4c4bec5ff51e2230e4d3ee69773c608ae255f04d wpt-pr: 44460

docs/index.bs

domenic · 2024-02-15T04:31:12Z

docs/index.bs

@@ -3195,6 +3238,11 @@ spec: storage; urlPrefix: https://storage.spec.whatwg.org/
      1. Else:
          1. Set |workerRealm| to the [=relevant realm=] of the |activeWorker|'s [=service worker/global object=].
          1. Set |eventHandled| to [=a new promise=] in |workerRealm|.
+          1. If |raceResponse| is not null, then:


Is it possible raceResponse will be set to a promise in step 13.4.3.1.1 of Handle Fetch, but never resolved with a response by step 13.4.3.1.2.1? Or, it will be rejected because of the fetch abort that occurs in step 13.4.4?

Now it might be "pending", I think? The map does not say it is allowed to contain "pending", but maybe it should be expanded to allow that?

domenic · 2024-02-15T04:31:47Z

docs/index.bs

+              1. Let |map| be |activeWorker|'s [=service worker/global object=]'s [=race response map=].
+              1. Let |token| be the result of [=generating a random UUID=].
+              1. [=map/Set=] |map|[|token|] to |raceResponse|.
+              1. Set |request|'s [=request/service-workers race token=] to |token|.


Is it possible to just make the map keyed by requests, instead of strings? Then you don't need this token setup.

Is it possible to get the map entry by using a struct (or object) as a key? If so that would be feasible.
On the other hand, the implementation side may become a bit difficult due to the type inconsistency of request.

Yes. In specs maps can be keyed by anything. There's no need to change the implementation; as long as the spec is observably equivalent, it is OK for them to depart.

But, be sure to distinguish between requests and Requests in the spec...

domenic · 2024-02-15T04:35:31Z

docs/index.bs

+              1. Let |raceFetchController| be null.
+              1. Run the following substeps [=in parallel=], but [=abort when=] |controller|'s [=fetch controller/state=] is "<code>terminated</code>" or "<code>aborted</code>":
+                  1. Set |raceFetchController| to the result of calling [=fetch=] given |request|, with [=fetch/processResponse=] set to the following steps given a [=/response=] |raceNetworkRequestResponse|:
+                      1. Set |raceResponse| to [=a new promise=].


I'm not sure promises work well here. Promises can only store JavaScript or IDL objects, like Response, but you are instead resolving them with a response. That isn't allowed.

You could try to wrap the response into a Response. I guess that would mean creating a new Response whose response is set to the response. But as explained in a comment later on, I don't think that is the right architecture. In general, I don't think using promises (which are main thread objects, very tied to JavaScript) inside this background-thread processing is a good idea.

Tried to update not to use promise here. Does that look better?

domenic · 2024-02-15T04:37:14Z

docs/index.bs

@@ -3236,6 +3284,10 @@ spec: storage; urlPrefix: https://storage.spec.whatwg.org/
              1. If |eventHandled| is not null, then [=reject=] |eventHandled| with a "{{NetworkError}}" {{DOMException}} in |workerRealm|.
              2. Return a [=network error=].
          1. If |eventHandled| is not null, then [=resolve=] |eventHandled|.
+          1. If |raceResponse| is not null, then:
+              1. [=promise/React=] to |raceResponse|:


You can't return from inside the react steps. Also, as discussed above, there is a type mismatch here: promises can only hold JavaScript objects, and you need to return a response, not a Response.

domenic

This is looking like it will work :).

docs/index.bs

domenic · 2024-02-15T07:08:56Z

docs/index.bs

@@ -3195,6 +3238,11 @@ spec: storage; urlPrefix: https://storage.spec.whatwg.org/
      1. Else:
          1. Set |workerRealm| to the [=relevant realm=] of the |activeWorker|'s [=service worker/global object=].
          1. Set |eventHandled| to [=a new promise=] in |workerRealm|.
+          1. If |raceResponse| is not null, then:


Now it might be "pending", I think? The map does not say it is allowed to contain "pending", but maybe it should be expanded to allow that?

domenic · 2024-02-15T07:11:21Z

docs/index.bs

+      :: |workerRealm|, a [=relevant realm=] of the [=service worker/global object=]
+      :: |reservedClient|, a [=request/reserved client=]
+      :: |preloadResponse|, a [=promise=]
+      :: |raceResponse|, a null, "<code>pending</code>" or [=/response=]


Parameter passing in specs generally follows JavaScript-style conventions. So, you cannot modify a parameter from outside the called algorithm, once it has been passed.

To get around this, create a tiny wrapper struct, with one item. Then the other algorithm can modify the struct item.

Now it might be "pending", I think? The map does not say it is allowed to contain "pending", but maybe it should be expanded to allow that?

Yes, in L3141, the state is either "pending" or [=/response=]. I'll update the map to accept "pending".

To get around this, create a tiny wrapper struct, with one item. Then the other algorithm can modify the struct item.

Added a new struct and use it to the parameter, but not fully confident if this direction is correct. Let me know the usage is wrong.

domenic · 2024-02-15T07:12:24Z

docs/index.bs

@@ -1079,7 +1079,7 @@ spec: storage; urlPrefix: https://storage.spec.whatwg.org/
      };
    </pre>

-    A {{ServiceWorkerGlobalScope}} object represents the global execution context of a [=/service worker=]. A {{ServiceWorkerGlobalScope}} object has an associated <dfn export for="ServiceWorkerGlobalScope">service worker</dfn> (a [=/service worker=]). A {{ServiceWorkerGlobalScope}} object has an associated <dfn for="ServiceWorkerGlobalScope">force bypass cache for import scripts flag</dfn>. It is initially unset.
+    A {{ServiceWorkerGlobalScope}} object represents the global execution context of a [=/service worker=]. A {{ServiceWorkerGlobalScope}} object has an associated <dfn export for="ServiceWorkerGlobalScope">service worker</dfn> (a [=/service worker=]). A {{ServiceWorkerGlobalScope}} object has an associated <dfn for="ServiceWorkerGlobalScope">force bypass cache for import scripts flag</dfn>. A {{ServiceWorkerGlobalScope}} object has an associated <dfn for="ServiceWorkerGlobalScope">race response map</dfn> which is an [=ordered map=] where the [=map/keys=] are [=requests=] and the [=map/values=] are <a>promises</a>. It is initially unset.


I think the map values are now "response"s?

"response"s or "pending"? I updated it with the new struct though.

sisidovski · 2024-02-15T08:19:19Z

docs/index.bs

+      : Input
+      :: |request|, a [=request=]
+      : Output
+      :: a [=race response=].


As this is called from the fetch spec, if possible, perhaps it's convenient to set just "<code>pending</code>", [=/response=], or null as an output.

Yes, I think unwrapping the struct would be better, so that the Fetch spec doesn't need to know about it. (And then you can avoid exporting it.)

Also, is Fetch really going to treat all three outcomes differently? Or maybe if it's still pending at the time of the call, it will treat pending the same as null? If so the you could handle that in this algorithm too.

Thanks! Updated to return [=/response=] or null. Fetch is going to treat if there is an map entry, which returns [=/response=], or no entry.

domenic

I gave a few samples of how to do the struct, but I did not comment on every access.

domenic · 2024-02-15T10:37:26Z

docs/index.bs

+      : Input
+      :: |request|, a [=request=]
+      : Output
+      :: a [=race response=].


Yes, I think unwrapping the struct would be better, so that the Fetch spec doesn't need to know about it. (And then you can avoid exporting it.)

Also, is Fetch really going to treat all three outcomes differently? Or maybe if it's still pending at the time of the call, it will treat pending the same as null? If so the you could handle that in this algorithm too.

docs/index.bs

domenic · 2024-02-15T10:40:46Z

docs/index.bs

      1. Let |timingInfo| be a new [=service worker timing info=].
+      1. Let |raceResponse| be null.


Here it would be: Set |raceResponse| to a [=race response=] whose [=race response/value=] is null.

I believe this is Let?

…t response, a=testonly Automatic update from web-platform-tests Use OK status to check RaceNetworkRequest response Reflecting the comment on yoshisatoyanagisawa/ServiceWorker#10 (comment) Bug: 1371756 Change-Id: I6de1fed384e32fbdae40799ef48d4ce2eeb3eccd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5276401 Reviewed-by: Minoru Chikamune <[email protected]> Reviewed-by: Yoshisato Yanagisawa <[email protected]> Reviewed-by: Kouhei Ueno <[email protected]> Commit-Queue: Shunya Shishido <[email protected]> Cr-Commit-Position: refs/heads/main@{#1257762} -- wpt-commits: 4c4bec5ff51e2230e4d3ee69773c608ae255f04d wpt-pr: 44460

sisidovski · 2024-02-15T18:37:09Z

docs/index.bs

@@ -3231,11 +3280,15 @@ spec: storage; urlPrefix: https://storage.spec.whatwg.org/

      1. Wait for |task| to have executed or for |handleFetchFailed| to be true.
      1. If |shouldSoftUpdate| is true, then [=in parallel=] run the [=Soft Update=] algorithm with |registration|.
+      1. If |raceResponseMap|[|request|] [=map/exists=], [=map/remove=] |raceResponseMap|[|request|].


This step is needed to remove the map entry, which is not consumed by Fetch. The fetch handler may not have fetch(e.request) e.g. fallback, offline etc. Otherwise map entries are infinitely added.

mkruisselbrink · 2024-02-15T22:28:45Z

docs/index.bs

+              1. Let |queue| be an empty [=queue=] of [=/response=].
+              1. Let |raceFetchController| be null.
+              1. Set |raceResponse|'s [=race response/value=] to "<code>pending</code>".
+              1. [=map/Set=] |activeWorker|'s [=service worker/global object=]'s [=race response map=][|request|] to |raceResponse|.


It might be simpler if the race response map is associates with activeWorker (i.e. a service worker) rather than its global scope? Especially as at this point in the algorithm the worker hasn't been started yet, so global object might very well be null.

That's a good point. How about keep the global scope having the map, and move this [=map/set=] to the step 16.2 in Create Fetch Event and Dispatch? At this point, Run Service Worker was already called to we can expect the global object is ready.

Updated as above. Let me know if this doesn't solve your concern.

…t response, a=testonly Automatic update from web-platform-tests Use OK status to check RaceNetworkRequest response Reflecting the comment on yoshisatoyanagisawa/ServiceWorker#10 (comment) Bug: 1371756 Change-Id: I6de1fed384e32fbdae40799ef48d4ce2eeb3eccd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5276401 Reviewed-by: Minoru Chikamune <chikamunechromium.org> Reviewed-by: Yoshisato Yanagisawa <yyanagisawachromium.org> Reviewed-by: Kouhei Ueno <kouheichromium.org> Commit-Queue: Shunya Shishido <sisidovskichromium.org> Cr-Commit-Position: refs/heads/main{#1257762} -- wpt-commits: 4c4bec5ff51e2230e4d3ee69773c608ae255f04d wpt-pr: 44460 UltraBlame original commit: 2fa7948b44b6df8c83ff94f083948147447baecc

domenic

LGTM!

docs/index.bs

Reflecting the comment on yoshisatoyanagisawa/ServiceWorker#10 (comment) Bug: 1371756 Change-Id: I6de1fed384e32fbdae40799ef48d4ce2eeb3eccd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5276401 Reviewed-by: Minoru Chikamune <[email protected]> Reviewed-by: Yoshisato Yanagisawa <[email protected]> Reviewed-by: Kouhei Ueno <[email protected]> Commit-Queue: Shunya Shishido <[email protected]> Cr-Commit-Position: refs/heads/main@{#1257762}

…t response, a=testonly Automatic update from web-platform-tests Use OK status to check RaceNetworkRequest response Reflecting the comment on yoshisatoyanagisawa/ServiceWorker#10 (comment) Bug: 1371756 Change-Id: I6de1fed384e32fbdae40799ef48d4ce2eeb3eccd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5276401 Reviewed-by: Minoru Chikamune <chikamunechromium.org> Reviewed-by: Yoshisato Yanagisawa <yyanagisawachromium.org> Reviewed-by: Kouhei Ueno <kouheichromium.org> Commit-Queue: Shunya Shishido <sisidovskichromium.org> Cr-Commit-Position: refs/heads/main{#1257762} -- wpt-commits: 4c4bec5ff51e2230e4d3ee69773c608ae255f04d wpt-pr: 44460 UltraBlame original commit: 2fa7948b44b6df8c83ff94f083948147447baecc

Reflecting the comment on yoshisatoyanagisawa/ServiceWorker#10 (comment) Bug: 1371756 Change-Id: I6de1fed384e32fbdae40799ef48d4ce2eeb3eccd Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5276401 Reviewed-by: Minoru Chikamune <[email protected]> Reviewed-by: Yoshisato Yanagisawa <[email protected]> Reviewed-by: Kouhei Ueno <[email protected]> Commit-Queue: Shunya Shishido <[email protected]> Cr-Commit-Position: refs/heads/main@{#1257762}

yoshisatoyanagisawa reviewed Feb 5, 2024

View reviewed changes

docs/index.bs Show resolved Hide resolved

yoshisatoyanagisawa reviewed Feb 5, 2024

View reviewed changes

docs/index.bs Outdated Show resolved Hide resolved

yoshisatoyanagisawa reviewed Feb 5, 2024

View reviewed changes

docs/index.bs Outdated Show resolved Hide resolved

yoshisatoyanagisawa reviewed Feb 5, 2024

View reviewed changes

docs/index.bs Outdated Show resolved Hide resolved

sisidovski added 3 commits February 6, 2024 10:02

Add race-network-and-fetch-handler option

569c3de

Abort the request if the fetch handler respond

ad5f0b9

Fix nav preload condition, indent, FetchEvent

10db402

sisidovski force-pushed the patch-2 branch from 3f5a45d to 10db402 Compare February 6, 2024 01:02

sisidovski marked this pull request as draft February 6, 2024 02:10

sisidovski added 3 commits February 6, 2024 16:08

Split Handle Fetch

e6e70bc

Fix id name and tags

e18d7ea

Restore old sentence

210fd4f

sisidovski marked this pull request as ready for review February 6, 2024 07:52

yoshisatoyanagisawa reviewed Feb 6, 2024

View reviewed changes

docs/index.bs Outdated Show resolved Hide resolved

yoshisatoyanagisawa reviewed Feb 6, 2024

View reviewed changes

docs/index.bs Outdated Show resolved Hide resolved

yoshisatoyanagisawa approved these changes Feb 6, 2024

View reviewed changes

Abort race request if not needed

8e087c8

domenic reviewed Feb 7, 2024

View reviewed changes

Fixed passing the error to [=fetch controller/Abort=], indentation, 2…

2e86804

…00 to [=ok status=], updated the caller for fetch |reqeuest|

chromium-wpt-export-bot mentioned this pull request Feb 8, 2024

Use OK status to check RaceNetworkRequest response web-platform-tests/wpt#44460

Merged

domenic reviewed Feb 9, 2024

View reviewed changes

Add fallback case

67561a6

yoshisatoyanagisawa mentioned this pull request Feb 13, 2024

Address comments in the main PR. #12

Merged

Add token and lookup algorithm

f8a0d3d

sisidovski mentioned this pull request Feb 14, 2024

Add service-workers race token to request and its lookup sisidovski/fetch#1

Closed

Drop incorrect note

fd5b794

domenic reviewed Feb 15, 2024

View reviewed changes

sisidovski added 2 commits February 15, 2024 15:33

Fix incorrect format, update the map key to be request

aa42d55

Do not use promise to manage [=/response=]

3245241

domenic reviewed Feb 15, 2024

View reviewed changes

Added the race response struct

01c0773

sisidovski commented Feb 15, 2024

View reviewed changes

domenic reviewed Feb 15, 2024

View reviewed changes

sisidovski added 2 commits February 16, 2024 03:02

Update race response struct

6d43556

Remove unconsumed map entry

27ccc75

sisidovski commented Feb 15, 2024

View reviewed changes

mkruisselbrink reviewed Feb 15, 2024

View reviewed changes

Move adidng an entry after run service worker

1cd657a

sisidovski force-pushed the patch-2 branch from 5d89faa to 1cd657a Compare February 16, 2024 01:44

Merge branch 'static_routing_api' into patch-2

4765d5c

domenic approved these changes Feb 16, 2024

View reviewed changes

docs/index.bs Outdated Show resolved Hide resolved

docs/index.bs Outdated Show resolved Hide resolved

docs/index.bs Outdated Show resolved Hide resolved

docs/index.bs Outdated Show resolved Hide resolved

docs/index.bs Outdated Show resolved Hide resolved

Fix editorial issues

bf4bdaf

yoshisatoyanagisawa merged commit c324260 into yoshisatoyanagisawa:static_routing_api Feb 16, 2024
1 check passed

sisidovski deleted the patch-2 branch February 16, 2024 04:47

		1. Let \|timingInfo\| be a new [=service worker timing info=].
		1. Let \|raceResponse\| be null.

Add race-network-and-fetch-handler option #10

Add race-network-and-fetch-handler option #10

Conversation

sisidovski commented Feb 5, 2024 • edited by pr-preview bot Loading

sisidovski commented Feb 5, 2024

sisidovski commented Feb 6, 2024 • edited Loading

yoshisatoyanagisawa commented Feb 6, 2024

sisidovski commented Feb 6, 2024

domenic commented Feb 7, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sisidovski Feb 9, 2024 • edited Loading

Choose a reason for hiding this comment

domenic Feb 14, 2024 • edited Loading

Choose a reason for hiding this comment

sisidovski Feb 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic left a comment

Choose a reason for hiding this comment

Add `race-network-and-fetch-handler` option #10

Add `race-network-and-fetch-handler` option #10

sisidovski commented Feb 5, 2024 •

edited by pr-preview bot

Loading

sisidovski commented Feb 6, 2024 •

edited

Loading

sisidovski Feb 9, 2024 •

edited

Loading

domenic Feb 14, 2024 •

edited

Loading

sisidovski Feb 14, 2024 •

edited

Loading