migrate lazy queries to Apollo Client 4

[Soxasora]

Description

Based on #2904

useLazyQuerys used outside of user interaction have the potential to throw AbortErrors much more frequently than before:

• The component unmounts while the query is in flight
• A new query is started by calling the execute function while a previous query is in flight
  _{ac4 migration}

We have some anti-patterns going on, some places should have useQuery and other places should use client.query

1. useLazyQuery + useEffect: the execute is only ran by useEffect and never reaches the user, can use useQuery with skip
   • BaseSuggest components/form.js
   • PostEdit pages/items/[id]/edit.js
2. only execute: doesn't use any of the following: data, loading, error and can use client.query
   • SubMultiSelect components/sub-select.js
   • TerritoryForm components/territory-form.js
   • useCrossposter components/use-crossposter.js
   • useLexicalUploadFees components/editor/plugins/upload.js
   • useSuggestions components/editor/plugins/mentions.js
   • components/payIn/hooks/use-auto-retry-pay-ins.js

While instead sub-popover.js, item-popover.js, user-popover.js, link-form.js, wallets/.../logger.js all use useLazyQuery correctly.

Additional Context

components/payIn/hooks/use-auto-retry-pay-ins.js polls correctly every 30 seconds, but I didn't do deep QA.

Checklist

Are your changes backward compatible? Please answer below:

Yes

On a scale of 1-10 how well and how have you QA'd this change and any features it might affect? Please answer below:

6, everything works smoothly, couldn't give it a 7 just because of missing QA on components/payIn/hooks/use-auto-retry-pay-ins.js

Did you use AI for this? If so, how much did it assist you?
Plan

---

Note

Medium Risk
Changes several async data-fetch paths (editor mention suggestions, territory lookups, post edit fee line items, and pay-in retry polling) to avoid Apollo Client 4 AbortError behavior; risk is moderate due to altered fetch timing/caching and error handling in user-facing and payment-related flows.

Overview
Migrates multiple non-interactive useLazyQuery usages to either useApolloClient().query (one-off fetches) or useQuery with skip (effect-driven fetches) to reduce Apollo Client 4 in-flight cancellation/AbortError issues.

This updates mention/autocomplete suggestion fetching, territory info lookups, crossposter item loading, and failed pay-in polling to use direct client.query with explicit fetch policies, and refactors pages/items/[id]/edit.js to derive territory-add fee line items from a SUBS useQuery result instead of an effect + lazy query.

^{Reviewed by Cursor Bugbot for commit f4fae62. Bugbot is set up for automated code reviews on this repo. Configure here.}

[huumn]

The main I issue I found with this was a regression in race conditions where successive queries can be executed and we need the last query rather than the last response (and we aren't debouncing otherwise). I'm not sure what the right move is, but we might want to establish some kind of abort/ignore pattern for these, debounce them (lowering the probability of races), or continue with useLazyQuery (which has the annoying abort pattern baked in).

• territory-form.js when checking for an archived territory
  • e.g. bitcoin is archived, I type out bitcoin then bitcoin1, bitcoin1 returns available but then the bitcoin response comes later and bitcoin1 is marked as archived
• components/editor/plugins/upload.js has a similar race

The other issue I found matched cursorbot's findings: suggestions and suggestions index can go out of sync now.

---

this is all bot review. by my eye it looks good - I would've missed the query races.

[Soxasora]

I couldn't reproduce without an artificial delay but this needs to be fixed anyway. We can probably keep useLazyQuery for some things, its abort mechanism is actually useful here.

I'll check where we need to switch back!

edit:

• territory-form and upload now use useLazyQuery again, it makes more sense to switch back and benefit from the abort mechanism.
• I was evaluating a switch back for BaseSuggest's mentions, but since we can benefit from cache access with useQuery it made sense to just fix the desync issue with an activeIndex computed on the current suggestions array state.

It seems like everything else is textbook correct.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8676013. Configure here.}