Feature not supported in current reactivity implementation

Error message

Feature not supported in current reactivity implementation

What it means

svelteReactivity() in packages/svelte-table returns a TableReactivityBindings object whose addSubscription method unconditionally throws. This reactivity implementation does not support external subscriptions; callers that request one hit this guard. It exists so unsupported binding APIs fail loudly instead of silently misbehaving.

Source

Thrown at packages/svelte-table/src/reactivity.svelte.ts:65

    }) as Atom<T>['subscribe'],
  }
}

/**
 * Creates the table-core reactivity bindings used by the Svelte adapter.
 *
 * Table state atoms are backed by TanStack Store atoms. The options store stays
 * framework-native because row-model APIs read `table.options` directly during
 * render. Readonly table atoms bridge Store dependency tracking into
 * `$derived.by`, so their `.get()` methods participate in Svelte dependency
 * tracking when called in templates, `$derived`, or `$effect`.
 */
export function svelteReactivity(): TableReactivityBindings {
  return {
    createOptionsStore: true,
    wrapExternalAtoms: false,
    addSubscription: () => {
      throw new Error(
        'Feature not supported in current reactivity implementation',
      )
    },
    unmount: () => {
      throw new Error(
        'Feature not supported in current reactivity implementation',
      )
    },
    schedule: (fn) => queueMicrotask(() => fn()),
    createReadonlyAtom: <T>(fn: () => T, _options?: TableAtomOptions<T>) => {
      const storeAtom = createAtom(() => fn(), {
        compare: _options?.compare,
      })
      let version = $state(0)

      $effect(() => {
        const subscription = storeAtom.subscribe(() => {
          version += 1

View on GitHub (pinned to d01c01bedb)

Solutions

Do not call addSubscription with the Svelte bindings; use the atoms/schedule APIs svelteReactivity provides instead.
If you need subscriptions, use a reactivity implementation that supports them (e.g. storeReactivityBindings) or implement a custom TableReactivityBindings with a working addSubscription.
Check the feature/integration you enabled to see why it registers subscriptions and disable or adapt it.

Example fix

// before
bindings.addSubscription(() => value)
// after
// subscribe via Svelte reactivity instead
$effect(() => {
  console.log(atom.get())
})

Defensive patterns

Strategy: validation

Validate before calling

const bindings = svelteReactivity()
if (bindings.addSubscription === undefined) throw new Error('subscriptions unsupported')
// or check a documented capability flag before using subscription APIs

Type guard

function supportsSubscriptions(b: TableReactivityBindings): boolean {
  return typeof b.addSubscription === 'function' && !isThrowingStub(b.addSubscription)
}

Try / catch

try {
  bindings.addSubscription(cb)
} catch (e) {
  if ((e as Error).message.includes('Feature not supported')) {
    // fall back to atom/effect-based tracking
  } else throw e
}

Prevention

Read the adapter's TableReactivityBindings surface before writing feature code against it
Prefer atom reads/effects over manual subscriptions in Svelte
Test features against every reactivity adapter you ship

When it happens

Trigger: Calling any table code path that invokes bindings.addSubscription(...) while using the Svelte reactivity bindings (svelteReactivity), e.g. a feature or atom consumer that registers a manual subscription against the table's reactivity layer.

Common situations: Using a table feature or integration written for the store-based reactivity (storeReactivityBindings) on the Svelte implementation; mixing reactivity adapters; library authors calling addSubscription directly.

Related errors

AI-assisted analysis of TanStack/table@d01c01bedb (2026-08-28). Data as JSON: /api/errors/04d3f0b301962aa2. Report an issue: GitHub.