feat: async RequestTransformFunction#7184
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #7184 +/- ##
==========================================
- Coverage 92.71% 92.46% -0.26%
==========================================
Files 289 289
Lines 24073 24074 +1
Branches 5108 5108
==========================================
- Hits 22320 22259 -61
- Misses 1753 1815 +62 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Thanks for taking the time to open this PR! |
I did it intentionally not to break the existing unit tests. I first tried to simply prepend |
|
@HarelM |
|
Thanks! |
|
@HarelM The only concern is that the extra microtask delay introduced by unconditionally awaiting |
|
Looks a lot better now, thanks! |
|
@HarelM Would mind me rebasing my branch to solve the conflict? Or would you prefer a merge commit? |
|
Whichever works for you, I'll squash merge it at the end... |
`RequestTransformFunction` may return a `Promise<RequestParameters>`. Clients of `RequestManager` prepare for the `transformRequest` method returning `Promise<RequestParameters>`. They check if the returned value from `transformRequest` is a `Promise` before awaiting it so that they do not disturbe the existing unit tests. Otherwise, we will get a lot of timeout errors.
Test all the modules that may call `transformRequest` execpt for `video_source`.
The new test case tests an edge case where the style JSON is not resolved by `Style` but by `Map`.
Modify existing unit tests to deal with an extra microtask delay introduced by unconditionally `await`ing `transformRequest`. `Style.loadURL` becomes `async`. I think it should not harm because it is not a public API and has no return value. There are still `instanceof Promise` checks in `geojson_source`, because it seems there is no simple workaround to the extra microtask delay. I guess we have to modify the logic in `geojson_source`, although, I have not come up with any solution. **Concern**: The extra microtask delay might cause subtle errors in some applications that depend on strict timing of the `transformRequest` resolution. **Background**: The `instanceof Promise` checks were introduced not to cause an extra microtask delay when the `transformRequest` is synchronous and not to break existing unit tests.
The point of this commit is to delay the resolution of the result of `_getLoadGeoJSONParameters` until the `_isUpdatingWorker` is set; i.e., inside `_dispatchWorkerUpdate`. Simply `await`ing the result of `_getLoadGeoJSONParameters` immediately after the call of the function breaks the behavior when `setData` or `setClusterOptions` are consecutively called. It would cause a race condition.
Because `setTimeout` cannot be awaited and might cause flaky tests. `delayServerRespond` is no longer necessary. Also remove redundant comments.
Fixes the test "modifying cluster properties with pending data" so that it reflects the latest behavior. In the latest `main` branch, data and cluster options are separatedly applied. Therefore, there are one more `sendAsync` calls.
1cff2be to
ed5e758
Compare
|
I've added some comments after latest merge from main, overall looks good. |
Co-authored-by: Harel M <harel.mazor@gmail.com>
Move expects from `sendAsync` to the body of each test function. Remove an unnecessary comment. Revert an unnecessary change.
Head branch was pushed to by a user without write access
|
@HarelM Sorry, I have pushed minor changes after your approval. |
|
No worries. Thanks for all the work on this! A great addition to this library. |
Proposed changes
Promise<RequestParameters>to the return type ofRequestTransformFunction; i.e., it may beasync.transformRequestis invoked so that no type errors are reported and existing unit tests won't break.async transformRequest. They are basically variants of existing unit tests involvingtransformRequest.Related issue
Launch Checklist
CHANGELOG.mdunder the## mainsection.