[Bug] Pinecone client doesn't initialize on Cloudfare workers or Vercel

[Blaizzy]

Is this a new bug?

• [X] I believe this is a new bug
• [X] I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior

When I try to initialise the client it throws errors

const pinecone = new Pinecone({
                apiKey: env.PINECONE_API_KEY,
                environment: env.PINECONE_ENVIRONMENT,
});

Cloudfare Error:

Error compiling schema, function code: const schema2 = scope.schema[2];const schema1 = scope.schema[1];return function validate1(data, {instancePath="", parentData, parentDataProperty, rootData=data}={}){let vErrors = null;let errors = 0;if(!(((typeof data == "number") && (!(data % 1) && !isNaN(data))) && (isFinite(data)))){const err0 = {instancePath,schemaPath:"#/definitions/nonNegativeInteger/type",keyword:"type",params:{type: "integer"},message:"must be integer"};if(vErrors === null){vErrors = [err0];}else {vErrors.push(err0);}errors++;}if((typeof data == "number") && (isFinite(data))){if(data < 0 || isNaN(data)){const err1 = {instancePath,schemaPath:"#/definitions/nonNegativeInteger/minimum",keyword:"minimum",params:{comparison: ">=", limit: 0},message:"must be >= 0"};if(vErrors === null){vErrors = [err1];}else {vErrors.push(err1);}errors++;}}validate1.errors = vErrors;return errors === 0;}
EvalError: Code generation from strings disallowed for this context
    at new Function (<anonymous>)
    at Ajv.compileSchema (file:///private/var/folders/c8/yj5plb7n12j4_dx2t602mjgw0000gn/T/tmp-36161-E863LF5hXPTq/index.js:10324:30)
    at Ajv.inlineOrCompile (file:///private/var/folders/c8/yj5plb7n12j4_dx2t602mjgw0000gn/T/tmp-36161-E863LF5hXPTq/index.js:10380:49)
    at Ajv.resolveRef (file:///private/var/folders/c8/yj5plb7n12j4_dx2t602mjgw0000gn/T/tmp-36161-E863LF5hXPTq/index.js:10374:47)
    at Object.code (file:///private/var/folders/c8/yj5plb7n12j4_dx2t602mjgw0000gn/T/tmp-36161-E863LF5hXPTq/index.js:12188:47)
    at keywordCode (file:///private/var/folders/c8/yj5plb7n12j4_dx2t602mjgw0000gn/T/tmp-36161-E863LF5hXPTq/index.js:10148:13)
    at file:///private/var/folders/c8/yj5plb7n12j4_dx2t602mjgw0000gn/T/tmp-36161-E863LF5hXPTq/index.js:9874:25
    at CodeGen.code (file:///private/var/folders/c8/yj5plb7n12j4_dx2t602mjgw0000gn/T/tmp-36161-E863LF5hXPTq/index.js:8139:11)
    at CodeGen.block (file:///private/var/folders/c8/yj5plb7n12j4_dx2t602mjgw0000gn/T/tmp-36161-E863LF5hXPTq/index.js:8266:16)
    at schemaKeywords (file:///private/var/folders/c8/yj5plb7n12j4_dx2t602mjgw0000gn/T/tmp-36161-E863LF5hXPTq/index.js:9874:13) {
  stack: EvalError: Code generation from strings disallowed…0000gn/T/tmp-36161-E863LF5hXPTq/index.js:9874:13),
  message: Code generation from strings disallowed for this context
}

Vercel Serverless/Edge functions:

ReferenceError: global not defined

Expected Behavior

I want to be able to run the pinecone client close to my LLM.

Steps To Reproduce

1. Install the latest client
2. Create a js file that initialises the client.

Relevant log output

No response

Environment

- **OS**:
- **Language version**:
- **Pinecone client version**:1.1.2

Additional Context

No response

[PlasticLizard]

Is there any workaround for this? Langchainjs requires 1.1.0 now, so I can't upgrade that without breaking in our cloudflare workers - hoping there is some alternative

[kenju]

@PlasticLizard AFAIU, the current workaround is to use the old deprecated PineconeClient in the meantime.

[RickRyan26]

@kenju Do you have a working version number? I can't find one. Thanks!

[PlasticLizard]

I'm using 0.0.12

It sucks because that version conflicts with all LangChain versions prior to 0.0.159, so we're locked into the relatively distant past, but it seems the best that can be done at the moment to run on CloudFlare.

[RickRyan26]

Oh nice, Thanks for the tip! No clue how elaborately you're using LangChain so this info might be worthless but if you're just using it for extending OpenAi, their new GPTs Assistants Beta API is making LangChain seem pretty obsolete to me.

[kenju]

@RickRyan26 Mine works with ^1.1.2 as well, the exported class is just marked as @deprecated and you need to use the deprecated methods. Here is an excerpt from my codebase:

import { PineconeClient } from '@pinecone-database/pinecone';
const pinecone = new PineconeClient()
await pinecone.init({
  apiKey: env.PINECONE_API_KEY,
  environment: env.PINECONE_ENVIRONMENT,
})
const index = pinecone.Index(env.PINECONE_INDEX_NAME)
const upsertResponse = await index.upsert({ upsertRequest: { vectors, } })

[marpontes]

• "@pinecone-database/pinecone": "^1.1.2",
  • "langchain": "^0.0.211",

I managed to make it work on Cloudflare Workers with the following workaround:

1. globals.d.ts

   declare global {
   var EdgeRuntime: string;
   }

2. index.ts

   globalThis.EdgeRuntime = "cloudflare" // the content doesn't really matter as long as it is a string

3. whatever-your-file-is.ts

   
   const pinecone = new Pinecone({
   apiKey: env.PINECONE_API_KEY,
   environment: env.PINECONE_ENVIRONMENT
   });

const pineconeIndex = pinecone.Index(env.PINECONE_INDEX_NAME);

// Langchain Vector Store vectorStore = await PineconeStore.fromExistingIndex( embeddings, { pineconeIndex } );

4. `wrangler.toml`
```toml
node_compat = true

---

• This workaround is primarily based on commit 36717482d1d78ffb9ea6b3a20682baa384a5a839 from @jhamon. In her description, she acknowledges the problem and conditions the use of ajv (or the evil eval) to the existence of the EdgeRuntime global variable as a string.
• However, setting the global variable alone wasn't sufficient for me since pinecone-ts-client depends on some Node.js globals like global and process. That's why turning node_compat = true was necessary.
• There is potentially a better way of backfilling these node variables, perhaps with @edge-runtime?

[rpatel15-hue]

Facing same issue when deploying to Vercel Edge api.

Issue Details:

• Error Message: Failed to compile. The error log points to ./node_modules/@pinecone-database/pinecone/node_modules/ajv/dist/compile/index.js.
• Core Problem: The root cause seems to be dynamic code evaluation (eval, new Function, WebAssembly.compile), which is not permitted in the Edge Runtime (reference: Next.js documentation).

Attempted Solutions and Further Issues:

1. Using Newer Pinecone Version:
   • Encountered the compilation error with the newer version of Pinecone, as detailed above.
2. Using Deprecated PineconeClient:
   • Using the deprecated PineconeClient leads to a type return mismatch. It returns VectorOperationsApi, which is not supported by Langchain. Langchain expects Index<RecordMetadata> from PineconeStore.fromExistingIndex.

Current Stance:

• Considering downgrading both Langchain and Pinecone, but uncertain about which versions to opt for to ensure compatibility with Vercel Edge deployment.
• Open to any other solutions or suggestions from the community.

[marpontes]

@rpatel15-hue have you tried setting EdgeRuntime global variable?

Refs:

• 1867083722
• 36717482d1d78ffb9ea6b3a20682baa384a5a839

[rpatel15-hue]

Hi @marpontes,

Thank you for your suggestion. I've attempted both the EdgeRuntime global variable approach and the unstable_allowDynamic configuration for Next.js, but I'm still encountering a compilation error.

Summary of my attempts:

1. EdgeRuntime global variable:

• Created globals.d.ts and set EdgeRuntime in index.ts as you described.
• However, there have been no changes in behavior.

• I'm facing a TypeScript error when trying to set the EdgeRuntime global variable in my index.ts file:

  Error: "Element implicitly has an 'any' type because type 'typeof globalThis' has no index signature.ts(7017)"

  Steps Taken:

  1. Created globals.d.ts.

  2. Attempted to set EdgeRuntime in index.ts:

  globalThis.EdgeRuntime = "vercel"; // Using "vercel" for Next.js Edge Runtime

  • Resolving TypeScript Error: How can I properly set the EdgeRuntime global variable in TypeScript without triggering this error?

2. unstable_allowDynamic configuration:

• Added the following configuration to my edge API route file:

  export const config = {
   runtime: 'edge',
   unstable_allowDynamic: [
     './node_modules/@pinecone-database/pinecone/**'
   ],
  }

Additional Questions (clarifications and additions):

1. Equivalent to node_compat = true for Next.js: Is there a mechanism in Next.js that provides Node.js compatibility features for the Edge Runtime, similar to Cloudflare's node_compat = true?

2. Alternative workarounds: Besides the EdgeRuntime variable, are there other known workarounds or compatibility approaches for using Pinecone with Langchain in Next.js Edge Runtime?

3. Specific guidance for Next.js: The referenced commit (3671748) doesn't provide Next.js-specific instructions. Is there any further guidance or examples tailored for Next.js?

For more information on Edge Dynamic Code Evaluation in Next.js, you can refer to the official Next.js documentation.

I would appreciate any further insights or suggestions you might have, especially those relevant to the Next.js environment.

[rpatel15-hue]

Hi everyone,

I wanted to update you on my progress with deploying on Next.js while using Langchain and Pinecone. I've found a temporary workaround that seems to be effective for now:

1. Pinecone Version Update: I upgraded Pinecone from version 1.1.0 to 1.1.2. While I'm not entirely sure if this was a decisive factor, it's part of the changes I made.

2. Typo Correction in Configuration: I identified and corrected a typo in the configuration path. The original path ./node_modules/@pinecone-database/pinecone/** was changed to /node_modules/@pinecone-database/pinecone/**. This adjustment appears to have had a significant impact.

3. Working Configuration: For those trying to deploy on Next.js and encountering similar issues, here's the configuration that I used:

   export const config = {
    runtime: 'edge',
    unstable_allowDynamic: ['/node_modules/@pinecone-database/pinecone/**'],
   };

I want to emphasize that this is a temporary workaround, and I'm not entirely sure whether the version update, the typo fix, or both together led to the success. However, after these changes, my application is now able to call the API in production without throwing errors.

I hope this workaround might be useful for others in a similar situation. If you're deploying on Next.js and using Langchain, you might want to give this configuration a try.

Would love to hear if this helps anyone else or if there are more permanent solutions being explored.

[RickRyan26]

Hi everyone,

I wanted to update you on my progress with deploying on Next.js while using Langchain and Pinecone. I've found a temporary workaround that seems to be effective for now:

1. Pinecone Version Update: I upgraded Pinecone from version 1.1.0 to 1.1.2. While I'm not entirely sure if this was a decisive factor, it's part of the changes I made.

2. Typo Correction in Configuration: I identified and corrected a typo in the configuration path. The original path ./node_modules/@pinecone-database/pinecone/** was changed to /node_modules/@pinecone-database/pinecone/**. This adjustment appears to have had a significant impact.

3. Working Configuration: For those trying to deploy on Next.js and encountering similar issues, here's the configuration that I used:

   export const config = {
    runtime: 'edge',
    unstable_allowDynamic: ['/node_modules/@pinecone-database/pinecone/**'],
   };

I want to emphasize that this is a temporary workaround, and I'm not entirely sure whether the version update, the typo fix, or both together led to the success. However, after these changes, my application is now able to call the API in production without throwing errors.

I hope this workaround might be useful for others in a similar situation. If you're deploying on Next.js and using Langchain, you might want to give this configuration a try.

Would love to hear if this helps anyone else or if there are more permanent solutions being explored.

Excited to try this thank you, sounds like a brilliant fix.

[rafalzawadzki]

Hi everyone, I wanted to update you on my progress with deploying on Next.js while using Langchain and Pinecone. I've found a temporary workaround that seems to be effective for now:

1. Pinecone Version Update: I upgraded Pinecone from version 1.1.0 to 1.1.2. While I'm not entirely sure if this was a decisive factor, it's part of the changes I made.
2. Typo Correction in Configuration: I identified and corrected a typo in the configuration path. The original path ./node_modules/@pinecone-database/pinecone/** was changed to /node_modules/@pinecone-database/pinecone/**. This adjustment appears to have had a significant impact.
3. Working Configuration: For those trying to deploy on Next.js and encountering similar issues, here's the configuration that I used:

   export const config = {
    runtime: 'edge',
    unstable_allowDynamic: ['/node_modules/@pinecone-database/pinecone/**'],
   };

I want to emphasize that this is a temporary workaround, and I'm not entirely sure whether the version update, the typo fix, or both together led to the success. However, after these changes, my application is now able to call the API in production without throwing errors. I hope this workaround might be useful for others in a similar situation. If you're deploying on Next.js and using Langchain, you might want to give this configuration a try. Would love to hear if this helps anyone else or if there are more permanent solutions being explored.

Excited to try this thank you, sounds like a brilliant fix.

Hi @RickRyan26, did it work for you?

[RickRyan26]

My team and I ended up going in a different direction so I'm not sure but I bet it will. Surprised pinecone hasn't fixed this yet

[nicitaacom]

@RickRyan26 Mine works with ^1.1.2 as well, the exported class is just marked as @deprecated and you need to use the deprecated methods. Here is an excerpt from my codebase:

Hey I have this issue

https://github.com/langchain-ai/langchainjs/discussions/4423

I just fixed it by installing old version of packages from here package.json

"@pinecone-database/pinecone": "^0.1.6",
"langchain": "^0.0.92",

[ShravanSunder]

I don't think node-fetch should imported if you are passing in a fetch function. This causes issues when using the pine cone library in plugins for rivet (v8 browser). Additionally, this would be an issue in cloudflare workers.

With node 18 LTS and after, not sure why we need an external library node-fetch as a default. node-fetch should be imported dynamically based on an option.

I think this would be the best way to make this package friendly across different runtimes. cc @jhamon

the user could easily just pass in any fetch function if a native fetch doesn't exist. This would easily solve a lot of issues in edge runtime.

    if (!this.config.fetch && typeof fetch === 'undefined') {
      throw new Error(
        'The Fetch API is not supported in this environment. Please provide an alternative, for example, node-fetch.'
      );
    }

[zwily]

Man this is disappointing... it's sort of rare these days to find client libraries that don't work on Cloudflare, or edge workers.