Implement `project.parameters.create` and `loadParameters` APIs by joshuawootonn · Pull Request #1298 · braintrustdata/braintrust-sdk

joshuawootonn · 2026-01-21T23:16:24Z

Related: https://github.com/braintrustdata/braintrust/pull/10207

Current State:

This PR is ready to go except for the question I have posted here. This is the first time, to my knowledge, that we are using a json schema to validate data, and I could use some advice on how to do that.

Demo:

CleanShot.2026-01-23.at.17.17.47.mp4

ankrgyl · 2026-01-21T23:25:14Z

small nit: should the PR be titled "Implement loadParameters API"?

joshuawootonn · 2026-01-21T23:28:51Z

Yes it should be. Thank you!

joshuawootonn · 2026-01-23T23:11:08Z

js/src/framework.ts

+      // todo(josh): at this point, I have a JSON schema, but I don't have something to use that JSON schema to validate my data.
+      // eslint-disable-next-line @typescript-eslint/consistent-type-assertions
+      const loadedData =
+        resolvedEvaluatorParams.data as unknown as InferParameters<EvalParameters>;
+      if (parameters && Object.keys(parameters).length > 0) {
+        // eslint-disable-next-line @typescript-eslint/consistent-type-assertions
+        parameters = {
+          ...loadedData,
+          ...parameters,
+        } as unknown as InferParameters<EvalParameters>;
+      } else {
+        parameters = loadedData;
+      }
+    } else if (resolvedEvaluatorParams) {
+      parameters = validateParameters(
+        parameters ?? {},
+        resolvedEvaluatorParams,
+      );


I could use some advice here. In the previous implementation, we always have the schema passed directly to the Eval. This meant we could use that schema to validate parameters, as you can see in the second branch of this if statement.

The schema is now passed to create.

export const myParameters = project.parameters.create({ name: "My Parameters", slug: "my-parameters", schema: { numSamples: z .number() .default(100) .describe("Number of samples to take from the dataset"), datasetName: z .string() .default("Animals") .describe("Name of the dataset to sample from"), }, });

We no longer have the zod schema when we loadParameters and therefore we don't have it in the actual eval function context either.

Eval(PROJECT_NAME, { experimentName: "My Eval", data: /* ... */ task: async (input, { parameters }) => { console.log("datasetName", parameters.datasetName); /* ... */ }, scores: /* ... */, parameters: loadParameters({ projectName: "My Project", slug: "my-parameters", }), });

We do have a JSON schema, but this SDK doesn't have a JSON schema parsing library installed currently, i'm not sure we want to install one. Do you have any suggestions on how I can validate this data?

I could see us requiring the schema for loadParameters, so that Eval could get the zod schema directly. That kinda sucks, but it might be inevitable

i think the type param you introduced is inevitable

Options in my mind:

Add ajv or similar and use the json schema to validate

Add [json-schema-to-zod](https://www.npmjs.com/package/json-schema-to-zod) or something similar and use the users zod to validate

In my mind option 1 doesn't sound too bad since we can lazy import, but let me know.

Yes this is a tricky problem.

I am not opposed to adding ajv as a dependency to the sdk and doing a best effort to validate against the json schema. That would be at least a bit of validation for the user.

Validating against the actual zod would be tricky without converting/adding some library. json-schema-to-zod is planned to be deprecated soon but will still work for zod3 schemas.

People using our SDK use it with both zod 3 and zod 4 at the moment.

Users using the sdk with zod4 would be able to use toJSONSchema and fromJSONSchema on their schemas.

We are still on zod 3 at the moment for our backend and internal schemas (which create the generated_types files) and is why all our sdk imports from zod needs to export from the /v3 path.

joshuawootonn · 2026-01-23T23:27:47Z

js/dev/server.ts

  return ret;
 }
-
-export function makeEvalParametersSchema(


I moved out of server so I could use this within the CLI.

joshuawootonn · 2026-01-23T23:29:36Z

js/src/prompt-cache/parameters-cache.ts

@@ -0,0 +1,69 @@
+import { RemoteEvalParameters } from "../logger";


This is a copy of prompts-cache.ts but for the parameter.

This might not be necessary. I got a bit confused because it seems like in some places prompt is used interchangeably for function.

yeah i'm not sure about this one. cc @manugoyal would know, i think

joshuawootonn · 2026-01-23T23:30:33Z

js/src/framework2.ts

+      function_type: "parameters",
+      function_data: {
+        type: "parameters",
+        data: {},


I'm initializing data to an empty object. Could also initialize it to null. It needs to be serializable though, so undefined doesn't work even thought it's the most accurate representation

joshuawootonn · 2026-01-23T23:31:36Z

js/src/prompt-schemas.ts

+import { z } from "zod/v3";
+import {
+  ToolFunctionDefinition as toolFunctionDefinitionSchema,
+  type ToolFunctionDefinitionType as ToolFunctionDefinition,
+  ChatCompletionMessageParam as chatCompletionMessageParamSchema,
+  ModelParams as modelParamsSchema,
+  type PromptBlockDataType as PromptBlockData,
+  type PromptDataType as PromptData,
+} from "./generated_types";
+
+// This roughly maps to promptBlockDataSchema, but is more ergonomic for the user.
+export const promptContentsSchema = z.union([
+  z.object({
+    prompt: z.string(),
+  }),
+  z.object({
+    messages: z.array(chatCompletionMessageParamSchema),
+  }),
+]);
+
+export type PromptContents = z.infer<typeof promptContentsSchema>;
+
+export const promptDefinitionSchema = promptContentsSchema.and(
+  z.object({
+    model: z.string(),
+    params: modelParamsSchema.optional(),
+    templateFormat: z.enum(["mustache", "nunjucks", "none"]).optional(),
+  }),
+);
+
+export type PromptDefinition = z.infer<typeof promptDefinitionSchema>;
+
+export const promptDefinitionWithToolsSchema = promptDefinitionSchema.and(
+  z.object({
+    tools: z.array(toolFunctionDefinitionSchema).optional(),
+  }),
+);
+
+export type PromptDefinitionWithTools = z.infer<
+  typeof promptDefinitionWithToolsSchema
+>;
+
+export function promptDefinitionToPromptData(
+  promptDefinition: PromptDefinition,
+  rawTools?: ToolFunctionDefinition[],
+): PromptData {
+  const promptBlock: PromptBlockData =
+    "messages" in promptDefinition
+      ? {
+          type: "chat",
+          messages: promptDefinition.messages,
+          tools:
+            rawTools && rawTools.length > 0
+              ? JSON.stringify(rawTools)
+              : undefined,
+        }
+      : {
+          type: "completion",
+          content: promptDefinition.prompt,
+        };
+
+  return {
+    prompt: promptBlock,
+    options: {
+      model: promptDefinition.model,
+      params: promptDefinition.params,
+    },
+    ...(promptDefinition.templateFormat
+      ? { template_format: promptDefinition.templateFormat }
+      : {}),
+  };
+}


Move this to a central location to avoid circular dependencies error in the zod tests

joshuawootonn · 2026-01-23T23:32:07Z

py/src/braintrust/_generated_types.py

+    __schema: FunctionDataFunctionData4Schema
+    """
+    JSON Schema describing the structure and types of the parameters data
+    """


Not sure how this regenerated. Open to dropping it.

The makefile target for regenerate-sdk-types currently generates backend types for both the typescript and the python sdk at the same time.

This should be good to leave in.

joshuawootonn · 2026-01-23T23:44:08Z

Why API compatibility is failing:

Evaluator interface - Type widening
The parameters property type changed:
Before: parameters?: Parameters;
After: parameters?: Parameters | RemoteEvalParameters<bool...
This widens the type to accept either the original Parameters type OR the new RemoteEvalParameters type (from loadParameters()).
EvaluatorFile type - New property added
A new parameters property was inserted:
Before: prompts: CodePrompt[]; evaluators: { [evalName: string]: ...
After: prompts: CodePrompt[]; parameters: CodeParameters[]; evaluators: { [evalName: string]: ...

Essentially, the type was widened on parameters. There's a new parameter property on the evaluator file.

I'm skeptical that we actually want to drop a major version for this diff, but let me know and I'll update the PR 🙏🏼

joshuawootonn · 2026-01-23T23:49:35Z

@colsondonohue and @j13huang eden mentioned you both as good reviewers for these changes. If there is someone on the SDK team that would be better for review lemme know 🙏🏼

#1298 (comment)

joshuawootonn · 2026-01-26T19:18:00Z

One thing I want to bring up is: With this new API your schema is no longer passed into the Eval so I don't think there is a way to infer the types for the task's parameters. Your schema is now passed to:

export const myParameters = project.parameters.create({
  name: "My Parameters",
  slug: "my-parameters",
  schema: {
    numSamples: z
      .number()
      .default(100)
      .describe("Number of samples to take from the dataset"),
    datasetName: z
      .string()
      .default("Animals")
      .describe("Name of the dataset to sample from"),
  },
});

In practice, this means a user has to manually pass the type of the schema. Curious how this feels. Am I over thinking it this? Or do we need to change this before launch?

Eval(PROJECT_NAME, {
  experimentName: "My Eval",
  data: /* ... */
  task: async (input, { parameters }) => {
    console.log("datasetName", parameters.datasetName);
    
    /* ... */
  },
  scores: /* ... */,
  parameters: loadParameters<typeof myParameters>({
    projectName: "My Project",
    slug: "my-parameters",
  }),
});

ankrgyl · 2026-01-26T19:23:53Z

One thing I want to bring up is: With this new API your schema is no longer passed into the Eval so I don't think there is a way to infer the types for the task's parameters. Your schema is now passed to:

export const myParameters = project.parameters.create({
  name: "My Parameters",
  slug: "my-parameters",
  schema: {
    numSamples: z
      .number()
      .default(100)
      .describe("Number of samples to take from the dataset"),
    datasetName: z
      .string()
      .default("Animals")
      .describe("Name of the dataset to sample from"),
  },
});

In practice, this means a user has to manually pass the type of the schema. Curious how this feels. Am I over thinking it this? Or do we need to change this before launch?

Eval(PROJECT_NAME, {
  experimentName: "My Eval",
  data: /* ... */
  task: async (input, { parameters }) => {
    console.log("datasetName", parameters.datasetName);
    
    /* ... */
  },
  scores: /* ... */,
  parameters: loadParameters<typeof myParameters>({
    projectName: "My Project",
    slug: "my-parameters",
  }),
});

This is a good question/point. I think it's a classic problem with database/code integrations. Supabase for example has a build step that fetches database schemas and updates the types accordingly. I'm not sure there is fundamentally a workaround for it. Or in other words, I think you do need to let people provide the type themselves, and anything we do on top of that is just helpful sugar that reduces the effort required. (I might be missing something, though).

joshuawootonn · 2026-01-26T19:40:55Z

This is a good question/point. I think it's a classic problem with database/code integrations. Supabase for example has a build step that fetches database schemas and updates the types accordingly. I'm not sure there is fundamentally a workaround for it. Or in other words, I think you do need to let people provide the type themselves, and anything we do on top of that is just helpful sugar that reduces the effort required. (I might be missing something, though).

Great point! Ok good to know. I hadn't really connected the dots that a build step would be the workaround.

Unless there is a build step like this in place, I think building something like that can be apart of the next "chunk" of work on this API.

colsondonohue

seems reasonable but i haven't worked in the sdk all that much. adding @ibolmo for a more expert opinion

colsondonohue · 2026-01-26T20:02:36Z

js/src/prompt-cache/parameters-cache.ts

@@ -0,0 +1,69 @@
+import { RemoteEvalParameters } from "../logger";


yeah i'm not sure about this one. cc @manugoyal would know, i think

colsondonohue · 2026-01-26T20:03:14Z

js/src/framework.ts

+      // todo(josh): at this point, I have a JSON schema, but I don't have something to use that JSON schema to validate my data.
+      // eslint-disable-next-line @typescript-eslint/consistent-type-assertions
+      const loadedData =
+        resolvedEvaluatorParams.data as unknown as InferParameters<EvalParameters>;
+      if (parameters && Object.keys(parameters).length > 0) {
+        // eslint-disable-next-line @typescript-eslint/consistent-type-assertions
+        parameters = {
+          ...loadedData,
+          ...parameters,
+        } as unknown as InferParameters<EvalParameters>;
+      } else {
+        parameters = loadedData;
+      }
+    } else if (resolvedEvaluatorParams) {
+      parameters = validateParameters(
+        parameters ?? {},
+        resolvedEvaluatorParams,
+      );


i think the type param you introduced is inevitable

colsondonohue · 2026-01-26T20:04:30Z

js/src/logger.ts

+ * @param options.slug The slug of the parameters to load.
+ * @param options.version An optional version of the parameters (to read). If not specified, the latest version will be used.
+ * @param options.environment Fetch the version of the parameters assigned to the specified environment (e.g. "production", "staging"). Cannot be specified at the same time as `version`.
+ * @param options.id The id of specific parameters to load. If specified, this takes precedence over all other parameters (project, slug, version).


version doesn't conflict with id, right? i guess you're saying if we provide a version that belongs to another prompt, we'll use the latest version for the provided id, rather than retrieving the prompt with the given version?

This comment is misleading. Claude modeled it after the existing comment for loadPrompt, which is also misleading. I'll update both.

For both loadPrompt and loadParameter, when you pass both id and version it by id and filters by version. So if you pass both id and version, it will return that id @ that version or throw if it doesn't exist.

colsondonohue · 2026-01-26T20:05:26Z

js/src/logger.ts

+  fetch,
+  forceLogin,
+  state: stateArg,
+}: LoadParametersOptions): Promise<


would be nice to use function overloads to enforce the mutual exclusivity of different params at the type level

I agree.

I think the main thing I want to prevent is someone passing version and environment. Based on your earlier comment (https://github.com/braintrustdata/braintrust-sdk/pull/1298/changes/BASE..c935b1e5dee6cda9e9a0d1ca408af4454844ad08#r2729064591) it should be fine to have version + id and environment + id.

After further review I can also make projectName + slug, projectId + slug, and id exclusive.

These overloads have been added.

joshuawootonn

Thanks for taking a look @colsondonohue 🙌🏼

joshuawootonn · 2026-01-26T20:35:10Z

js/src/logger.ts

+ * @param options.slug The slug of the parameters to load.
+ * @param options.version An optional version of the parameters (to read). If not specified, the latest version will be used.
+ * @param options.environment Fetch the version of the parameters assigned to the specified environment (e.g. "production", "staging"). Cannot be specified at the same time as `version`.
+ * @param options.id The id of specific parameters to load. If specified, this takes precedence over all other parameters (project, slug, version).


This comment is misleading. Claude modeled it after the existing comment for loadPrompt, which is also misleading. I'll update both.

For both loadPrompt and loadParameter, when you pass both id and version it by id and filters by version. So if you pass both id and version, it will return that id @ that version or throw if it doesn't exist.

joshuawootonn · 2026-01-26T20:37:14Z

js/src/logger.ts

+  fetch,
+  forceLogin,
+  state: stateArg,
+}: LoadParametersOptions): Promise<


I agree.

I think the main thing I want to prevent is someone passing version and environment. Based on your earlier comment (https://github.com/braintrustdata/braintrust-sdk/pull/1298/changes/BASE..c935b1e5dee6cda9e9a0d1ca408af4454844ad08#r2729064591) it should be fine to have version + id and environment + id.

cpinn · 2026-01-29T18:05:04Z

py/src/braintrust/_generated_types.py

+    __schema: FunctionDataFunctionData4Schema
+    """
+    JSON Schema describing the structure and types of the parameters data
+    """


The makefile target for regenerate-sdk-types currently generates backend types for both the typescript and the python sdk at the same time.

This should be good to leave in.

cpinn · 2026-01-29T18:13:15Z

js/src/prompt-cache/parameters-cache.ts

+  return `parameters:${prefix}:${key.slug}:${key.version ?? "latest"}`;
+}
+
+export class ParametersCache {


I think this makes sense if I am understanding correctly.

Now parameters are stored separately than prompts. In that case when we cache the prompt it may not have the parameters so cache the parameters separately.

Let me know if I understand this correctly. If so I think having a cache on the parameters you are using with the prompt makes sense unless the parameters are also stored with the prompt itself(?)

cpinn · 2026-01-29T18:23:49Z

js/src/framework.ts

+      // todo(josh): at this point, I have a JSON schema, but I don't have something to use that JSON schema to validate my data.
+      // eslint-disable-next-line @typescript-eslint/consistent-type-assertions
+      const loadedData =
+        resolvedEvaluatorParams.data as unknown as InferParameters<EvalParameters>;
+      if (parameters && Object.keys(parameters).length > 0) {
+        // eslint-disable-next-line @typescript-eslint/consistent-type-assertions
+        parameters = {
+          ...loadedData,
+          ...parameters,
+        } as unknown as InferParameters<EvalParameters>;
+      } else {
+        parameters = loadedData;
+      }
+    } else if (resolvedEvaluatorParams) {
+      parameters = validateParameters(
+        parameters ?? {},
+        resolvedEvaluatorParams,
+      );


Yes this is a tricky problem.

I am not opposed to adding ajv as a dependency to the sdk and doing a best effort to validate against the json schema. That would be at least a bit of validation for the user.

Validating against the actual zod would be tricky without converting/adding some library. json-schema-to-zod is planned to be deprecated soon but will still work for zod3 schemas.

People using our SDK use it with both zod 3 and zod 4 at the moment.

Users using the sdk with zod4 would be able to use toJSONSchema and fromJSONSchema on their schemas.

We are still on zod 3 at the moment for our backend and internal schemas (which create the generated_types files) and is why all our sdk imports from zod needs to export from the /v3 path.

cpinn · 2026-01-29T19:54:39Z

Why API compatibility is failing:

Evaluator interface - Type widening
The parameters property type changed:
Before: parameters?: Parameters;
After: parameters?: Parameters | RemoteEvalParameters<bool...
This widens the type to accept either the original Parameters type OR the new RemoteEvalParameters type (from loadParameters()).

EvaluatorFile type - New property added
A new parameters property was inserted:
Before: prompts: CodePrompt[]; evaluators: { [evalName: string]: ...
After: prompts: CodePrompt[]; parameters: CodeParameters[]; evaluators: { [evalName: string]: ...

Essentially, the type was widened on parameters. There's a new parameter property on the evaluator file.

I'm skeptical that we actually want to drop a major version for this diff, but let me know and I'll update the PR 🙏🏼

@ibolmo I know we discussed previously allowing a bypass of the api-compatibility, do you think we should add that now?

I do kind of think this change should at least be a minor due to the additional parameter for the evaluator file parameters but major does seem a bit drastic in this case. I know we are about to release the 3.0 version.

@joshuawootonn is there any way we could make the parameters param optional?

cpinn · 2026-01-29T21:51:38Z

js/src/framework.ts

    GenericFunction<unknown, unknown>
  >[];
  prompts: CodePrompt[];
+  parameters: CodeParameters[];


@joshuawootonn this is the parameter I am talking about that became required.

yeah we should try to make this optional/nullable. score one for the api compat test

Just pushed up make it optional, and I'm initializing it if it's optional too

ibolmo · 2026-02-03T19:43:03Z

js/src/generated_types.ts

  z.null(),
 ]);
 export type ObjectReferenceNullishType = z.infer<typeof ObjectReferenceNullish>;
-export const SavedFunctionId = z.union([


hmm a little worried of these reverts

Thanks for checking this. Dropping my merge commit and rebasing on main fixed the issue.

ibolmo · 2026-02-03T19:43:46Z

js/src/generated_types.ts

  audit_data: z.union([z.array(z.unknown()), z.null()]).optional(),
  _async_scoring_state: z.unknown().optional(),
-  facets: z.union([z.object({}).partial().passthrough(), z.null()]).optional(),
-  classifications: z


looks like the we are missing this. i'd make sure your branch(es) are on the latest and see if regenerating brings this back

Thanks for checking this. Same as above

ibolmo · 2026-02-03T19:46:02Z

py/src/braintrust/_generated_types.py

 class ExtendedSavedFunctionIdExtendedSavedFunctionId(TypedDict):
    type: Literal['function']
    id: str
-    version: NotRequired[str | None]


yeah same thing here.. 🤔

Thanks for checking this. Same as above

…moving prompt schema stuff to it's own file

…with TS utility type

#1298 (comment)

…lts` handles this for us

ibolmo · 2026-02-03T20:59:43Z

py/src/braintrust/_generated_types.py



-class GitMetadataSettings(TypedDict):
+class GitMetadataSettings(TypedDict, closed=True):


this one is interesting. double check that you're using python 3.11. i think this is a python 3.15 only feature?

That's weird.

running again

ibolmo

sorry one more round to double check the closed=True (appears in python 3.15)

joshuawootonn changed the title ~~Implement loadParameterAPI~~ Implement loadParameter API Jan 21, 2026

joshuawootonn changed the title ~~Implement loadParameter API~~ Implement loadParameters API Jan 21, 2026

joshuawootonn force-pushed the josh/latest-parameters-2 branch 2 times, most recently from 56870fb to 1a3f392 Compare January 23, 2026 21:31

joshuawootonn commented Jan 23, 2026

View reviewed changes

joshuawootonn changed the title ~~Implement loadParameters API~~ Implement project.parameters.create and loadParameters API Jan 23, 2026

joshuawootonn changed the title ~~Implement project.parameters.create and loadParameters API~~ Implement project.parameters.create and loadParameters APIs Jan 23, 2026

joshuawootonn marked this pull request as ready for review January 23, 2026 23:44

joshuawootonn requested review from colsondonohue and j13huang January 23, 2026 23:48

joshuawootonn added a commit that referenced this pull request Jan 26, 2026

Temporary fix for default not being applied

2aa4e47

#1298 (comment)

joshuawootonn added a commit that referenced this pull request Jan 26, 2026

Temporary fix for default not being applied

8658092

#1298 (comment)

joshuawootonn force-pushed the josh/latest-parameters-2 branch from 2aa4e47 to 8658092 Compare January 26, 2026 17:20

colsondonohue reviewed Jan 26, 2026

View reviewed changes

colsondonohue requested a review from ibolmo January 26, 2026 20:09

joshuawootonn commented Jan 26, 2026

View reviewed changes

joshuawootonn requested review from clutchski and cpinn January 27, 2026 23:45

cpinn reviewed Jan 29, 2026

View reviewed changes

joshuawootonn requested a review from ankrgyl as a code owner January 29, 2026 21:24

cpinn reviewed Jan 29, 2026

View reviewed changes

joshuawootonn force-pushed the josh/latest-parameters-2 branch from f230038 to ec2b8e7 Compare January 29, 2026 22:07

ibolmo reviewed Feb 3, 2026

View reviewed changes

joshuawootonn added 21 commits February 3, 2026 13:56

Implement create for Parameters

bf290d7

Implement loadParameters for getting a version of a parameter entity

e0e171e

Update generated types

cbf2253

Update generated python types (not sure if this should be happening)

b29cc81

Update Eval to handle loadParameters

b9c0c28

Fix cd js && make docs failing in ci

935a99d

Update import in zod version tests that was causing CI failures

47020fe

Fix circular dependency between framework2.ts and eval-parameters by …

5c0c30d

…moving prompt schema stuff to it's own file

Name Parameters RemoteEvalParameters internally to prevent conflicts …

59ec3f6

…with TS utility type

Temporary fix for default not being applied

cc3d918

#1298 (comment)

Update exports to include ParameterSource

8a521b9

Remove ambiguity in id tsdoc comments on loadParameters and loadPrompts

45cffdc

Create function overloads for typechecking loadParameters

30f8e0e

Validate Parameters with AJV

cab2d0a

Make the parameters optional

a0fce32

Update api compatibility to handle union widening

e5147af

Update SDK to store json schema rather than a object of schemas

c520fc3

Remove unnecessary manual default value handling since AJV `withDefua…

5dc0726

…lts` handles this for us

Add AJV to deno config for CI errors

ec24d51

Move zod tests back to testing hardcoded parameters schema

3157603

Update PR with based on Olmo's feedback

05c782c

joshuawootonn force-pushed the josh/latest-parameters-2 branch from 929c8a5 to 05c782c Compare February 3, 2026 19:59

Running make regenerate-sdk-types

0e05228

ibolmo reviewed Feb 3, 2026

View reviewed changes

Disable closed type dict

23b41d1

ibolmo approved these changes Feb 4, 2026

View reviewed changes

joshuawootonn merged commit 4db0473 into main Feb 4, 2026
101 of 102 checks passed

joshuawootonn deleted the josh/latest-parameters-2 branch February 4, 2026 00:01

		@@ -0,0 +1,69 @@
		import { RemoteEvalParameters } from "../logger";



		class GitMetadataSettings(TypedDict):
		class GitMetadataSettings(TypedDict, closed=True):

Conversation

joshuawootonn commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Current State:

Demo:

Uh oh!

ankrgyl commented Jan 21, 2026

Uh oh!

joshuawootonn commented Jan 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joshuawootonn commented Jan 23, 2026

Why API compatibility is failing:

Uh oh!

joshuawootonn commented Jan 23, 2026

Uh oh!

joshuawootonn commented Jan 26, 2026

Uh oh!

ankrgyl commented Jan 26, 2026

Uh oh!

joshuawootonn commented Jan 26, 2026

Uh oh!

colsondonohue left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joshuawootonn left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cpinn commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why API compatibility is failing:

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ibolmo Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

joshuawootonn commented Jan 21, 2026 •

edited

Loading

cpinn commented Jan 29, 2026 •

edited

Loading

ibolmo Jan 29, 2026 •

edited

Loading

joshuawootonn Jan 29, 2026 •

edited

Loading