[renovate-coveo]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@coveo/headless (source)	3.55.4 → 3.58.0

---

Release Notes

coveo/ui-kit (@​coveo/headless)

v3.58.0

Compare Source

Minor Changes

• #​8704 a873e42 - Add an optional per-request navigatorContext to fetchStaticState(), hydrateStaticState() and build() in @coveo/headless/ssr. It applies to that call only, without mutating the shared engine definition, so concurrent requests no longer risk sending each other's client ID, user agent or x-forwarded-for address. When it is omitted, the provider set with setNavigatorContextProvider() is still used. The "Missing navigator context" warning and the setNavigatorContextProvider() deprecation notice now point to this option.

Patch Changes

• #​8669 5d3b308 - Remove a controller's listener from the engine when its last subscriber unsubscribes, whatever the order in which its subscribers unsubscribe. Before, the listener was only removed when the first subscriber was also the last to unsubscribe. Otherwise it stayed registered, and the controller kept comparing its state on every state change for the rest of the session.

• #​8693 8af7566 - Fix @coveo/headless/ssr sending the first request's x-forwarded-for header on every later request. fetchStaticState() stored its forwarded-for wrapper on the shared engine definition, and that wrapper kept reading the navigator context of the request that created it, so later setNavigatorContextProvider() calls no longer changed the header. Each engine now gets its own wrapper, on a copy of the definition options, so each request forwards its own address.

• #​8698 0a95379 - Deprecate getAccessToken() and setAccessToken() on the @coveo/headless/ssr engine definition, as on @coveo/headless/ssr-commerce. To renew an expiring token, configure renewAccessToken; to change the token of an engine you already have, dispatch updateBasicConfiguration({accessToken}) from loadConfigurationActions(engine).

• #​8695 480c745 - Correct the deprecation notice of ControllerDefinitionOption, which types the listing and search options of seven @coveo/headless/ssr-commerce definers such as definePagination. It said the interface was no longer used; it now says these options will be removed in the next major version, and to omit them so the controller is built for both search and product listing pages. The documentation of the seven definers now says the same, because editors don't show the interface's notice where these options are passed.

• #​8702 a292905 - Fix three misleading deprecation notices on the SSR commerce sub-packages. FetchStaticStateOptions no longer points to BuildConfig, which @coveo/headless/ssr-commerce doesn't export. defineCart now names the cart controller. The navigatorContext prop of the @coveo/headless-react/ssr-commerce providers no longer says to set the navigator context when fetching the static state.

• #​8694 2f1cde8 - Stop the SSR "Missing navigator context" warning from recommending the deprecated setNavigatorContextProvider. On @coveo/headless/ssr-commerce, it now says to pass navigatorContext to fetchStaticState() and hydrateStaticState(). On @coveo/headless/ssr, it says to pass a navigatorContextProvider to defineSearchEngine(), which the setNavigatorContextProvider deprecation notice now recommends too, instead of a navigatorContext option that fetchStaticState() doesn't accept.

v3.57.3

Compare Source

Patch Changes

• #​8627 ef62433 - Exclude the selected value from commerce category facet search results by sending its path in ignorePaths.

v3.57.2

Compare Source

Patch Changes

• Updated dependencies [2535634]:
  • coveo.analytics@​2.33.1

v3.57.1

Compare Source

Patch Changes

• #​8500 cf041b2 - Clarify in the setNavigatorContextProvider deprecation notice that it mutates the shared engine definition and is therefore unsafe under server concurrency, and point to passing navigatorContext per request when fetching the static state.

• #​8516 3c4e3d2 - Fix an issue in commerce where a manually set numeric facet range persisted and was still sent in subsequent queries after clearing filters (e.g. via a search box submission), even though it had been removed from the URL parameters.

v3.57.0

Compare Source

Minor Changes

• #​8494 3ed8932 - feat(headless): support a per-request access token in SSR commerce fetchStaticState() and hydrateStaticState()

  The @coveo/headless/ssr-commerce engine definition now accepts an optional accessToken when
  fetching the static state, hydrating it, or calling build(). It overrides the definition's
  configured token for that call only, without mutating the shared definition — the supported way to
  use per-user search tokens in a multi-tenant server process. When omitted, the definition's
  configured token is used.

  Pass the same token to hydrateStaticState() that was used for fetchStaticState() so the hydrated
  engine keeps querying with the same permissions. The hydrated engine outlives the call, so it stays
  subscribed to setAccessToken() updates; the request-scoped engine built by fetchStaticState()
  does not, which keeps a per-request token safe from concurrent updates on the shared definition.

• #​8495 a01e1f3 - feat(headless): support a per-request navigator context in SSR commerce fetchStaticState() and hydrateStaticState()

  The @coveo/headless/ssr-commerce engine definition now accepts an optional navigatorContext when
  fetching the static state, hydrating it, or calling build(). It is applied to that call only,
  without mutating the shared definition. When omitted, the provider set with
  setNavigatorContextProvider is used.

  This also removes the shared-options mutation on the static-state path, which caused a more serious
  problem than a race. fetchStaticState() used to assign the forwarded-for wrapper onto the shared
  configuration.preprocessRequest, and that wrapper resolves its navigator context from the options
  object it captured. Because the augmentation short-circuits on an already-wrapped function, the
  wrapper created by the first request was reused for the lifetime of the process — so every subsequent
  request sent the first request's x-forwarded-for value, regardless of any later
  setNavigatorContextProvider() call. The augmentation now happens per request, on a copy, so each
  request forwards its own address.

• #​8504 9e88f88 - BREAKING (open alpha) @coveo/headless/ssr-commerce-next: removed getAccessToken() and
  setAccessToken() from the commerce engine definitions, along with the shared access-token manager
  behind them.

  The access token is now configured the same way as navigatorContext: per request, through the build
  config, with no setter on the shared definition. This removes a class of concurrency bug — the shared
  token manager pushed updates into engines that had already been built with their own per-request
  token, so a queued or concurrent setAccessToken() could silently replace one request's token.

  Migrate as follows:

  • To choose the token for a request, pass accessToken to fetchStaticState(). It is returned with
    the static state, so passing that static state to hydrateStaticState() carries the token to the
    client automatically.
  • To rotate an expiring token on an engine that is already running, configure renewAccessToken on
    the engine configuration. The engine renews proactively before a request and reactively on an
    unauthorized response.

  @coveo/headless/ssr-commerce is unchanged: getAccessToken() and setAccessToken() still work
  there but are now deprecated, with the same migration path.

• #​8505 c3d3669 - @coveo/headless/ssr-next: added an optional per-request accessToken to the search BuildConfig,
  so fetchStaticState() and hydrateStaticState() can use a per-user search token without mutating
  the shared engine definition. When omitted, the definition's configured token is used.

  BREAKING (open alpha) removed getAccessToken() and setAccessToken() from the search engine
  definitions, along with the shared access-token manager behind them.

  The access token is now configured like navigatorContext: per request, through the build config,
  with no setter on the shared definition. setAccessToken() wrote to the module-level definition that
  every request reads, so two overlapping requests could cross tokens and one user could issue requests
  under another user's permissions.

  Migrate as follows:

  • To choose the token for a request, pass accessToken to fetchStaticState(). It is returned with
    the static state, so passing that static state to hydrateStaticState() carries the token to the
    client automatically.
  • To rotate an expiring token on an engine that is already running, configure renewAccessToken on
    the engine configuration. The engine renews proactively before a request and reactively on an
    unauthorized response.

  This brings the search engine definition in line with the commerce one.

v3.56.0

Compare Source

Minor Changes

• #​8481 01434bc - feat(headless): support a per-request access token in SSR commerce fetchStaticState()

  fetchStaticState() (and hydrateStaticState()) in /ssr-commerce-next now accept an optional
  accessToken in their build config. When provided, it overrides the engine definition's configured
  access token for that request only, without mutating the shared definition — the supported way to
  use per-user Coveo search tokens in a multi-tenant server process. When omitted, the definition's
  configured token is used, so the change is fully backward compatible.

Patch Changes

• #​8480 818bdf0 - fix(headless): bound the memoized relay-instance selector to prevent unbounded growth

  getRelayInstanceFromState used reselect's default weakMapMemoize, which never evicts
  primitive cache keys. Because the selector is keyed by accessToken (a string), servers using
  per-user search tokens accumulated one cache entry per distinct token for the lifetime of the
  process. The selector now uses a bounded lruMemoize cache, keeping the memoization benefit while
  capping retention. The change is internal — no public API changes.

• #​8464 e8c6ee4 - Fixed an issue in the insight panel where calling fetchMoreResults more than once re-fetched the same batch of results instead of fetching the next one.

  Fixed the insight panel's fetchMoreResults analytics logging, which was silently dropped because an action factory was passed instead of a dispatchable analytics action.

• #​8479 fa2e9de - Fix a memory leak in the SSR access-token manager. The manager held token-update callbacks in a
  plain Set, and because the manager lives at module scope for the whole process, every engine
  built through buildFactory (fetchStaticState, hydrateStaticState, and build()) was retained
  for the process lifetime — an unbounded, per-request leak of the Redux store, logger, relay
  instance, and API client.

  The registry is now weak: callbacks are held through WeakRef and anchored to their owner engine
  via a WeakMap, and a FinalizationRegistry prunes dead entries. The garbage collector now
  releases a subscription once its engine is unreachable, which fixes every path in both the commerce
  and search trees, with no behavior change for engines that are still alive (a hydrated browser
  engine keeps receiving token updates).

---

Configuration

📅 Schedule: (in timezone America/Toronto)

• Branch creation
  • "before 6:00am on Tuesday"
• Automerge
  • "after 9:00am and before 12:00pm on tuesday, wednesday, thursday"

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate CLI.

[svcsnykcoveo]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.