Update API specifications with fern api update

[wintonzheng]

Update API specifications by running fern api update.

---

Important

Update skyvern_openapi.json by removing order, adding expression, and renaming branches to branch_conditions.

• API Specification Updates:
  • Remove order field from BranchCondition in skyvern_openapi.json.
  • Add expression field to BranchCriteria and make it required in skyvern_openapi.json.
  • Rename branches to branch_conditions in ConditionalBlock in skyvern_openapi.json.

^{This description was created by for da7e6a2. You can customize this summary. It will automatically update as commits are pushed.}

---

🔄 This PR updates the API specifications for the Skyvern OpenAPI schema, specifically refactoring the conditional branching system by removing the order field from BranchCondition, adding an expression field to BranchCriteria, and renaming branches to branch_conditions in the ConditionalBlock schema.

🔍 Detailed Analysis

Key Changes

• BranchCondition Schema: Removed the order integer field and its requirement, along with the is_default boolean field remaining optional
• BranchCriteria Schema: Added a new required expression string field alongside the existing criteria_type field
• ConditionalBlock Schema: Renamed the branches property to branch_conditions and updated the description to clarify "list-ordered conditions"

Technical Implementation

flowchart TD
    A[ConditionalBlock] --> B[branch_conditions array]
    B --> C[BranchCondition objects]
    C --> D[BranchCriteria with expression]
    C --> E[is_default flag]
    
    F[Old Structure] --> G[order field required]
    F --> H[branches property name]
    
    I[New Structure] --> J[expression field required]
    I --> K[branch_conditions property name]
    I --> L[list-ordered evaluation]
    
    style F fill:#ffcccc
    style I fill:#ccffcc

Loading

Impact

• API Consistency: Improves naming conventions by using branch_conditions instead of branches for better clarity
• Expression-Based Logic: The new expression field in BranchCriteria enables more flexible condition evaluation beyond simple ordering
• Simplified Ordering: Removes explicit order field in favor of implicit list-based ordering, reducing complexity while maintaining deterministic behavior

Created with Palmier

Summary by CodeRabbit

• Refactor
  • Restructured conditional block schema: removed the order requirement from branch conditions, making them more flexible
  • Added a new required expression field to branch criteria for enhanced control
  • Renamed branches property to branch_conditions to better reflect functionality
  • Updated descriptions for consistency across conditional block structures

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

This pull request updates the OpenAPI schema definitions in fern/openapi/skyvern_openapi.json, removing the order property from BranchCondition, adding an expression property to BranchCriteria, and renaming the branches collection to branch_conditions in ConditionalBlock with updated descriptions.

Changes

Cohort / File(s)	Summary
OpenAPI Schema Updates fern/openapi/skyvern_openapi.json	Removed order property and requirement from BranchCondition; added expression string property to BranchCriteria required fields; renamed ConditionalBlock branches to branch_conditions with updated title and description for list-ordered condition selection

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

• Single file modification with straightforward schema definition changes
• Changes are homogeneous in nature (property removal, addition, and renaming)
• No complex logic or behavioral changes to evaluate

Possibly related PRs

• Update API specifications with fern api update #4085: Introduced the initial conditional-block features that are being refined by these schema modifications
• ConditionalBlock spec Update + Implementation for BranchCondition and BranchCriteria #4120: Directly modifies the same branching model with identical schema updates (expression field, order removal, branch conditions renaming)
• rename conditional_block.branches -> branch_conditions #4121: Directly related through the ConditionalBlock.branches to ConditionalBlock.branch_conditions rename

Suggested labels

sync, wintonzheng

Poem

🐰 A schema hops and shifts in form,
No order needed—flow's the norm,
With expression clear, the branches bloom,
List-ordered pathways light the room,
Conditions dance in structured grace!

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'Update API specifications with fern api update' is vague and generic, using non-descriptive terminology that doesn't convey the specific nature of the schema changes (removal of ordering, addition of expression field, property renaming).	Consider a more specific title like 'Update OpenAPI schema with conditional block and branch criteria changes' to better reflect the substantive API modifications.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch update-openapi-spec-2025-11-28T00-31-07-074Z

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0e7953f and da7e6a2.

📒 Files selected for processing (1)

• fern/openapi/skyvern_openapi.json (4 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Run tests and pre-commit hooks

🔇 Additional comments (2)

fern/openapi/skyvern_openapi.json (2)

5301-5304: I'll help you verify the concerns raised in this review comment about the new required expression field in BranchCriteria. Let me investigate the codebase to confirm whether this is indeed a breaking change and check for existing usage patterns.
<function_calls>

cat -n fern/openapi/skyvern_openapi.json | sed -n '5290,5330p'

</function_calls>

<function_calls>

rg -n "criteria_type" fern/openapi/skyvern_openapi.json -B2 -A2

</function_calls>

<function_calls>

rg -n "BranchCriteria" fern/openapi/skyvern_openapi.json -B2 -A2

</function_calls>

<function_calls>

find . -type f ( -name ".json" -o -name ".py" -o -name ".ts" -o -name ".js" ) -exec rg -l "criteria_type" {} ;

</function_calls>

<function_calls>

find . -type f ( -name "test" -o -name "spec" ) -name "*.json" | head -20

</function_calls>

<function_calls>

rg -n "expression" fern/openapi/skyvern_openapi.json | grep -i branch

</function_calls>

---

5908-5914: Based on my verification:

The breaking change premise ("branches → branch_conditions rename") cannot be verified from this codebase. No "branches" field exists anywhere in the current codebase, and git history shows only one commit. Without evidence of a prior "branches" field, the breaking change claim is unverifiable. However, the schema improvement suggestions remain valid.

Regarding Fern/OpenAPI deprecation: Fern does not provide an x-fern-property-rename extension for schema fields. The workaround is to keep both properties with a deprecated flag if a transition period is needed.

---

Schema lacks constraints; recommended additions for robustness.

The current branch_conditions schema (lines 5908–5914) lacks constraints that should be enforced:

• Add minItems: 1 to ensure at least one branch condition exists.
• Inside BranchCondition: require next_block_label and make criteria conditionally required (required only when is_default is false).
• Document ordering semantics: "The first matching condition wins; at most one branch may be marked is_default."

Proposed schema additions:

           "branch_conditions": {
             "items": {
               "$ref": "#/components/schemas/BranchCondition"
             },
             "type": "array",
+            "minItems": 1,
             "title": "Branch Conditions"
           }
@@
-        "description": "Branching block that selects the next block label based on list-ordered conditions."
+        "description": "Branching block that selects the next block label based on list order of branch_conditions. The first matching condition wins; at most one branch may be marked is_default."

Inside BranchCondition (schema definition near line 5301–5304), ensure criteria is required unless is_default: true, and next_block_label is always required. JSON Schema cannot cleanly enforce "at most one default" without application-level validation.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to da7e6a2 in 1 minute and 47 seconds. Click for details.

• Reviewed 71 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 4 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. fern/openapi/skyvern_openapi.json:5282

• Draft comment:
  Removal of 'order' property in BranchCondition might break clients. Confirm if this change is intentional.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

2. fern/openapi/skyvern_openapi.json:5299

• Draft comment:
  New 'expression' property added to BranchCriteria without a description. Consider adding one for clarity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This comment is suggesting that the author add a description to the new property for clarity. However, this falls into the category of "not clearly a code change required" - it's more of a suggestion for documentation improvement. The code will work fine without a description field in the OpenAPI schema. Additionally, the existing criteria_type field also doesn't have a description, so this isn't inconsistent with the existing pattern. The comment is also somewhat minor and could be considered "obvious or unimportant" - the title "Expression" is already somewhat self-documenting. According to the rules, I should not comment unless there is clearly a code change required, and this is more of a nice-to-have documentation improvement rather than a necessary change. The comment could be valid if documentation standards require description fields for all properties in OpenAPI schemas. Without knowing the project's documentation standards, I might be incorrectly dismissing a legitimate documentation requirement. While documentation standards could exist, the comment uses "Consider adding" language which is suggestive rather than directive, and the existing code already has properties without descriptions (like criteria_type), suggesting this isn't a hard requirement. The rules explicitly state not to comment unless there's clearly a code change required, and this is at best a documentation enhancement. This comment should be deleted because it's a suggestion for documentation improvement rather than a clearly required code change. It uses "Consider" language and the existing pattern shows properties without descriptions are acceptable.

3. fern/openapi/skyvern_openapi.json:5908

• Draft comment:
  Renaming 'branches' to 'branch_conditions' is a breaking change. Ensure all clients are updated accordingly.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to ensure that all clients are updated due to a breaking change. This falls under the rule of not asking the author to ensure behavior is intended or tested. It doesn't provide a specific suggestion or ask for a specific confirmation about the code itself.

4. fern/openapi/skyvern_openapi.json:5922

• Draft comment:
  Updated description in ConditionalBlock: 'list-ordered conditions' might be less clear. Verify that it accurately reflects behavior.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

Workflow ID: wflow_A1HHLk16CvTS61FR

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}