Hi I.P.,

Thanks for the reproducers; they made both issues easy to check.

I'm fairly new to the Ignite code, so a committer may want to double-check,
but here's what I found when I tested your scenarios on master:

   1. Local IndexQuery ignores setLimit. You're right, this is a bug, and
   it's still on master. A local query with setLimit(3) returns all rows. I'll
   file a JIRA ticket and work on a fix. Until then, a workaround could be to
   stop reading the cursor after the first N rows.
   2. Local ContinuousQuery in a shared cache group. You're right that 2.17
   and 2.18 have this bug, but IGNITE-28750 already fixed it on master, and
   the fix will be in 2.19. I tested your scenario on master for both ATOMIC
   and TRANSACTIONAL caches, and the writes now succeed. Until you can
   upgrade, your own workaround (keeping that cache out of the shared group)
   is the right one.

Best regards,
Reza

On Wed, Oct 21, 2026 at 11:36 AM <[email protected]> wrote:

> hi devs
>
> in the same stream as it was with my previous report here this month
> (email-based) about a regression in 2.18.0, it looks like that I might
> found another issues with the local query behavior in Ignite 2.x.
>
> Those are about:
>
>    - local IndexQuery ignores setLimit() property
>    - local ContinuousQuery in a shared cache breaks writes to the group's
>    other caches
>
> I used again an AI to generate a reproducer with a detailed README.md
> including a description about expected behavior (btw I verified that the
> issues are presented in 2.17.x as well).
>
> Could somebody please review it if I'm not mistaken with my findings and
> if it turns out to be true - assist for further actions with those bugs?
>
> Many thanks in advance.
>
> Best regards,
> I.P.
>
> P.S. The reproducer is in the attachment.
>
>

Reply via email to