@borngraced please fix wasm lint and PR name lint (like "allow first result using IDB cursor")

@borngraced please fix wasm lint and PR name lint (like "allow first result using IDB cursor")

done

Will duplicate note in the PR.
fixes till this commit 7ae981b solve runtime error. However in the last commit closure invoked issues occur again.

Also there is a problem with oneshot canceled when mm2 was stopped

However in the last commit closure invoked issues occur again.

I actually wanted to ask whether it solves the issue with cursor only when we need the first found item. I assume a more general fix is preferred because this one looks like a temporary workaround.

However in the last commit closure invoked issues occur again.

I actually wanted to ask whether it solves the issue with cursor only when we need the first found item. I assume a more general fix is preferred because this one looks like a temporary workaround.

It turned out that whole problem was in obtaining the first item. In CursorDriver::next method.
So fix should solve issue.

UPD: previously when we were trying to get one item by next(), the process continued in loop

However in the last commit closure invoked issues occur again.

I actually wanted to ask whether it solves the issue with cursor only when we need the first found item. I assume a more general fix is preferred because this one looks like a temporary workaround.

CursorAction doesn't know Closure was dropped immediately we returned from the function that called
next() to get first result so it tries to send another event to get the next result just millisecs after CursorDriver/Closure was dropped so I think Implementing first() can be a good fix too as we also don't need to loop to request first result.
cc. @artemii235

pub(crate) async fn next(&mut self) -> CursorResult<Option<(ItemId, Json)>> {
        loop {
            ...
            match cursor_action {
                CursorAction::Continue => cursor.continue_().map_to_mm(|e| CursorError::AdvanceError {
                    description: stringify_js_error(&e),
                })?,
                CursorAction::ContinueWithValue(next_value) => {
                    cursor
                        .continue_with_key(&next_value)
                        .map_to_mm(|e| CursorError::AdvanceError {
                            description: stringify_js_error(&e),
                        })?
                },
                // Don't advance the cursor.
                // Here we set the `stopped` flag so we return `Ok(None)` at the next iteration immediately.
                // This is required because `item_action` can be `CollectItemAction::Include`,
                // and at this iteration we will return `Ok(Some)`.
                CursorAction::Stop => self.stopped = true,
            };

            match item_action {
                CursorItemAction::Include => return Ok(Some(item.into_pair())),
                // Try to fetch the next item.
                CursorItemAction::Skip => (),
            }
        }
    }


     /// if getting the first result is what we want
    pub(crate) async fn first(&mut self) -> CursorResult<Option<(ItemId, Json)>> {
        let event = match self.cursor_item_rx.next().await {
            Some(event) => event,
            None => return Ok(None),
        };

        let _cursor_event = event.map_to_mm(|e| CursorError::ErrorOpeningCursor {
            description: stringify_js_error(&e),
        })?;

        let cursor = match cursor_from_request(&self.cursor_request)? {
            Some(cursor) => cursor,
            // No more items.
            None => return Ok(None),
        };

        let (_, js_value) = match (cursor.key(), cursor.value()) {
            (Ok(key), Ok(js_value)) => (key, js_value),
            // No more items.
            _ => return Ok(None),
        };

        let item: InternalItem =
            deserialize_from_js(js_value).map_to_mm(|e| CursorError::ErrorDeserializingItem(e.to_string()))?;

        Ok(Some(item.into_pair()))
    }
    ```
    

@laruh i improved the impl. so you can test it again. thanks

@borngraced recheck clippy or fmt please, CI fails

@borngraced recheck clippy or fmt please, CI fails

not an issue with my pr? https://github.com/KomodoPlatform/komodo-defi-framework/actions/runs/7166781305/job/19511514652?pr=2028#step:3:8

not an issue with my pr? https://github.com/KomodoPlatform/komodo-defi-framework/actions/runs/7166781305/job/19511514652?pr=2028#step:3:8

Hmm lets rerun to check

UPD: yeah, its not your branch issue. locally its fine.

I actually wanted to ask whether it solves the issue with cursor only when we need the first found item. I assume a more general fix is preferred because this one looks like a temporary workaround.

I agree with this, we should maybe have a limit function instead of first where we specify limit as 1 for first item. We can also add an until function which loops until a condition is found, maybe instead of until we can add where condition that can be used with limit. Since this case is not solved

https://github.com/KomodoPlatform/komodo-defi-framework/blob/4b364decc80701befa7c374c9a5182ace4b92f69/mm2src/coins/utxo/utxo_block_header_storage/wasm/indexeddb_block_header_storage.rs#L239-L262

After many hours of debugging I found another fix which introduces a method called where_ that takes a closure. The closure returns a boolean, allowing you to control when a loop should stop. This approach works reliably in various situations.

full explanation: #2028 (comment)

cc. @shamardy @laruh

@borngraced
can confirm that the last commit f8f1940 from impl_first_method_for_cursor branch + this commit from impl_first_method_for_cursor-test_nft_with_where_ branch dont have runtime errors

You can cherry pick the last commit from impl_first_method_for_cursor-test_nft_with_where_

we should maybe have a limit function instead of first

@borngraced Thanks for the great find and fix. Can we use condition to request a certain number of items? I asked for a limit or similar functionalities to not get all items for cases like below where we currently fetch all items then we just return the limit requested (requested page).
https://github.com/KomodoPlatform/komodo-defi-framework/blob/e61c41ea6fdce607f0b928b940e4fefb070b72f3/mm2src/mm2_main/src/lp_swap/my_swaps_storage.rs#L212-L272
You can see how limit and offset is used with sqlite to get only the values required
https://github.com/KomodoPlatform/komodo-defi-framework/blob/e61c41ea6fdce607f0b928b940e4fefb070b72f3/mm2src/mm2_main/src/database/my_swaps.rs#L216-L228
P.S. Maybe this enhancement can be done in another PR if it's too much to do here since it's unrelated to closure invoked recursively or after being dropped error. I actually don't know how much overhead we currently have by fetching all values.

we should maybe have a limit function instead of first

@borngraced Thanks for the great find and fix. Can we use condition to request a certain number of items? I asked for a limit or similar functionalities to not get all items for cases like below where we currently fetch all items then we just return the limit requested (requested page).

https://github.com/KomodoPlatform/komodo-defi-framework/blob/e61c41ea6fdce607f0b928b940e4fefb070b72f3/mm2src/mm2_main/src/lp_swap/my_swaps_storage.rs#L212-L272

You can see how limit and offset is used with sqlite to get only the values required
https://github.com/KomodoPlatform/komodo-defi-framework/blob/e61c41ea6fdce607f0b928b940e4fefb070b72f3/mm2src/mm2_main/src/database/my_swaps.rs#L216-L228

P.S. Maybe this enhancement can be done in another PR if it's too much to do here since it's unrelated to closure invoked recursively or after being dropped error. I actually don't know how much overhead we currently have by fetching all values.

We can use indexedb curosor.advance to achieve similar behavior as offset since there's no such functionalities in indexeded yet

and something like this for limit

const limit = 10;
let count = 0;
if cursor && count < limit {
  cursor.continue();
  count++;
}

but I'll research and explore other options for sure