main.dart.js -- Generated file improper usage of .toString

[MichealReed]

After generating my edge function, I received

error: Uncaught TypeError: Cannot read properties of undefined (reading 'toString')
      t1.toString;

      t1 = A._asStringQ(self.Deno.env.get("OPENAI_API_KEY"));
      t1.toString;

I'm not sure if the code generation is directly handled by dart edge. As you can see, the root of this comes from a Deno.env variable. It may be more proper to always add these to a empty string. The issue is fixed after removing

t1.toString;

I think this happens because of the way this library maps the String value to the OpenAI type -- OpenAI.apiKey = edge.Deno.env.get('OPENAI_API_KEY')!;

the occurrence of this convention might be rare, but this issue will at minimum serve to help others know they can simply remove the .toString from generated code.

[Ehesp]

Is this error at runtime? What's the Dart code to cause this error (is it simply using the environment variable?)

[MichealReed]

I had it happen yesterday with a different env variable too on a diff function. Yes, this is just assigning a string to the OpenAI api key (also a string). Maybe related to #29?

[MichealReed]

Maybe certain characters in the string trigger this? Every time I build I have to go in and remove the toString here --

[MichealReed]

Another case of weird casting ---

final examples =
        jsonDecode(body['examples']) as List<Map<String, dynamic>>;

becomes

examples = type$.List_Map_String_dynamic._as(B.C_JsonCodec.decode$2$reviver(A._asString(body.$index(0, "examples")), null));

with error

<ref *1> _TypeError { "__rti$_message": "TypeError: Instance of 'JSArray<dynamic>': type 'JSArray<dynamic>' is not a subtype of type 'String'", "$thrownJsError": <ref *2> TypeError: Instance of 'JSArray<dynamic>': type 'JSArray<dynamic>' is not a subtype of type 'String'

because of the _asString call.

[henry2man]

Another case of weird casting ---

final examples =
        jsonDecode(body['examples']) as List<Map<String, dynamic>>;

A possible workaround: use final/var in variables and simplify casting ops...

This will likely cause some issues, but at least the code will work until we have a solution.