v4 engine version selection logic updated

[ericallam]

We now hardcode engine version V2 when using the v4 packages, and now we'll fallback to using the project engine version when all these conditions are met:

• The engine version is NOT passed to the trigger task service (e.g. using an older SDK or doing an raw HTTP request
• A non-development environment
• There is no current version deployed

Previously it defaulted to V1 in that case.

Summary by CodeRabbit

• Refactor
  • Improved the process for determining the worker deployment engine version, ensuring that the system now dynamically derives the value from project settings rather than relying on fixed defaults.
  • Streamlined API communications by consistently setting the engine version header, contributing to more reliable and predictable deployment behavior.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 8130c35

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai]

Walkthrough

This pull request revises the engine version determination logic across the codebase. It replaces the deprecated function findCurrentWorkerDeploymentWithoutTasks with the new getCurrentWorkerDeploymentEngineVersion method in both the engine version and worker deployment modules. The worker deployment function now uses a simplified query (via findFirst) and returns a specific engine version (RunEngineVersion) based on a type check. Additionally, the API client’s header assignment for "x-trigger-engine-version" is simplified to always set the value to "V2", eliminating conditional logic based on the worker context.

Changes

File(s)	Change Summary
apps/webapp/app/v3/engineVersion.server.ts apps/webapp/app/v3/models/workerDeployment.server.ts	Replaced findCurrentWorkerDeploymentWithoutTasks with getCurrentWorkerDeploymentEngineVersion. In the worker deployment model, changed the query from findUnique to findFirst, selecting only the type field, and updated the return type to RunEngineVersion with conditional logic to return "V1", "V2", or undefined.
packages/core/src/v3/apiClient/index.ts	Streamlined header assignment in the ApiClient by removing the dependency on taskContext.worker?.engine and directly setting "x-trigger-engine-version" to "V2".

Sequence Diagram(s)

sequenceDiagram
    participant EV as EngineVersion.server
    participant WD as WorkerDeployment Model
    participant PE as Project Engine Fallback

    EV->>WD: Call getCurrentWorkerDeploymentEngineVersion(envId, label)
    alt Engine version found
        WD-->>EV: Return "V1" or "V2"
        EV->>EV: Use returned engine version
    else No engine version found
        WD-->>EV: Return undefined
        EV->>PE: Get default engine version from project
        PE-->>EV: Return default version
    end

Loading

Possibly related PRs

• Fix worker deployment engine version #1820: Updates the worker deployment type based on engine version, aligning with the changes in engine version determination.
• Improve worker deployment queries #1616: Alters the query method from findUnique to findFirst in worker deployment functions, paralleling similar modifications in this PR.

Poem

I'm a rabbit with a code-filled heart,
Hopping through changes, playing my part.
New functions bloom like a spring delight,
Engine versions dance from day to night.
With every hop, the logic feels just right!

---

📜 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 51bb3ee and 8130c35.

📒 Files selected for processing (3)

• apps/webapp/app/v3/engineVersion.server.ts (2 hunks)
• apps/webapp/app/v3/models/workerDeployment.server.ts (2 hunks)
• packages/core/src/v3/apiClient/index.ts (1 hunks)

🧰 Additional context used

🧬 Code Definitions (1)

apps/webapp/app/v3/engineVersion.server.ts (1)

apps/webapp/app/v3/models/workerDeployment.server.ts (1)

• getCurrentWorkerDeploymentEngineVersion (94-117)

⏰ Context from checks skipped due to timeout of 90000ms (3)

• GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
• GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
• GitHub Check: units / 🧪 Unit Tests

🔇 Additional comments (6)

packages/core/src/v3/apiClient/index.ts (1)

976-976: Hardcoded engine version to "V2"

The engine version is now hardcoded to "V2" instead of being conditionally set based on the worker's engine. This change aligns with the PR objective of consistently using V2 engine when utilizing v4 packages.

apps/webapp/app/v3/engineVersion.server.ts (3)

5-6: Updated import to use new function

Correctly updated the import to use getCurrentWorkerDeploymentEngineVersion instead of the deprecated findCurrentWorkerDeploymentWithoutTasks.

---

68-73: Improved engine version determination

Now using the more focused getCurrentWorkerDeploymentEngineVersion function which directly returns the engine version rather than the entire worker deployment object. This simplifies the code and makes its intent clearer.

---

75-75: Enhanced fallback mechanism

Updated the fallback to use the project's engine version instead of a hardcoded "V1". This change improves flexibility and aligns with the PR objective of introducing a fallback mechanism that uses the project's engine version when no current version is deployed.

apps/webapp/app/v3/models/workerDeployment.server.ts (2)

2-2: Added necessary import

Added RunEngineVersion to imports, which is needed for the return type of the new function.

---

94-117: Implemented focused engine version retrieval

The new getCurrentWorkerDeploymentEngineVersion function is a more efficient replacement for findCurrentWorkerDeploymentWithoutTasks. It:

1. Returns only the engine version instead of the entire worker deployment object
2. Minimizes the database query by selecting only the type field
3. Includes proper type checking for robustness
4. Normalizes engine versions to either "V1" or "V2"

This change aligns perfectly with the PR objective of updating the engine version selection logic and providing more consistent behavior.

✨ Finishing Touches

• 📝 Generate Docstrings

---

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

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai plan to trigger planning for file edits and PR creation.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.