FlowiseAI/Flowise · error · Error

Method ${method} is not available on the RPC object

Error message

Method ${method} is not available on the RPC object

What it means

The built filter function, when invoked on an RPC object, checks `typeof result[method] !== 'function'` before each call. If an allowed-method name is not actually present as a function on the runtime RPC/builder object, it throws 'Method ${method} is not available on the RPC object'. This is a runtime guard complementing the static allowlist.

Source

Thrown at packages/components/nodes/vectorstores/Supabase/filterParser.ts:190

            // Simple array parsing - just split by comma and parse each element
            return arrayContent.split(',').map((item) => this.parseArgument(item.trim()))
        }

        // For everything else, treat as string (but validate it doesn't contain dangerous characters)
        if (arg.includes('require') || arg.includes('process') || arg.includes('eval') || arg.includes('Function')) {
            throw new Error(`Potentially dangerous argument: ${arg}`)
        }

        return arg
    }

    private static buildFilterFunction(chain: Array<{ method: string; args: any[] }>): (rpc: any) => any {
        return (rpc: any) => {
            let result = rpc

            for (const { method, args } of chain) {
                if (typeof result[method] !== 'function') {
                    throw new Error(`Method ${method} is not available on the RPC object`)
                }

                try {
                    result = result[method](...args)
                } catch (error) {
                    throw new Error(`Failed to call ${method}: ${error.message}`)
                }
            }

            return result
        }
    }
}

View on GitHub (pinned to abe4a8601a)

Solutions

1. Confirm the installed @supabase version actually exposes the method on the builder at runtime.
2. Apply the filter function to the correct chainable object (e.g. the return of `.rpc(name)`), not a final result.
3. Pin or upgrade the Supabase client to a version whose builder matches the parser's allowlist.
4. Reorder chain so terminal methods (single/maybeSingle) come last.

Example fix

// before: const fn = FilterParser.parseFilterString('single()'); fn(rpcResult)  // result lacks .single
// after: const fn = FilterParser.parseFilterString('filter("a","eq",1).single()'); fn(client.rpc('match'))

function assertBuilderHasMethod(builder: any, method: string) {
  if (typeof builder?.[method] !== 'function') throw new Error(`Method '${method}' missing on builder; check @supabase version`)
}

function isChainableBuilder(v: any): boolean { return v != null && ['filter','order','limit'].some(m => typeof v[m] === 'function') }

try { result = result[method](...args) } catch (e) { /* handled by 557 */ }

When it happens

Trigger: The Supabase client/builder shape changed (method removed or renamed in a newer version); the filter is applied to an object that is not a PostgREST builder (e.g. a raw RPC return value); version drift between the parser's assumptions and the installed @supabase/postgrest-js.

Common situations: Upgrading @supabase/supabase-js where a builder method was renamed/removed; applying the filter function to the wrong object type; `maybeSingle`/`single` ordering on a non-chainable result.

Related errors

• Failed to call ${method}: ${error.message}
• Failed to parse Supabase filter: ${error.message}
• No valid filter methods found
• ${e}
• Error inserting: ${res.error.message} ${res.status} ${res.st

AI-assisted analysis of FlowiseAI/Flowise@abe4a8601a (2026-08-12). Data as JSON: /api/errors/56344303ad5fb68d. Report an issue: GitHub.