feat(launchdarkly): add LaunchDarkly integration for feature flag management

[waleedlatif1]

Summary

• Add LaunchDarkly integration with 12 tools: list/get/create/update/toggle/delete flags, get flag status, list projects/environments/segments/members, get audit log
• Add block with operation dropdown, conditional fields, API key auth
• Add icon, docs, registry entries

Type of Change

• New feature

Testing

Tested manually

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 31, 2026 11:27pm

[cursor]

PR Summary

Medium Risk
Introduces new external API tooling and a new block wired into global registries, so misconfiguration or response-shape issues could affect workflows using the new integration. Changes are otherwise additive and isolated.

Overview
Adds a new LaunchDarkly integration end-to-end: a LaunchDarklyBlock with an operation dropdown and conditional inputs, plus 12 new tools for flag lifecycle management (list/get/create/update/toggle/delete), flag status, projects/environments/segments/members, and audit log access using API-key authentication.

Wires the integration into the product and docs surfaces by registering the block and tools (blocks/registry.ts, tools/registry.ts), adding the launchdarkly entry to integration metadata/landing JSON, extending category typing to include feature-flags, and introducing a shared LaunchDarklyIcon used in both apps along with a new docs page (launchdarkly.mdx).

^{Written by Cursor Bugbot for commit cc9bceb. Configure here.}

[greptile-apps]

Greptile Summary

This PR adds a complete LaunchDarkly integration with 12 tools covering feature flag CRUD, toggling, status checks, and organization management (projects, environments, segments, members, audit log). The implementation follows established patterns for block/tool registration, uses correct user-only visibility for API keys, proper semantic-patch headers for mutating endpoints, and consistent URL encoding throughout.

Key changes:

• 12 new tool files under apps/sim/tools/launchdarkly/ with shared type constants in types.ts
• Block config in apps/sim/blocks/blocks/launchdarkly.ts with conditional field display and string-to-boolean coercions for the UI dropdowns
• Icon, registry, docs, and integration metadata additions follow the established project patterns correctly
• One concern: update_flag.ts throws an Error inside the body() request-builder function when no update instructions are provided — this is an unconventional pattern compared to every other tool in the PR (which surface errors via transformResponse), and may cause an unhandled exception rather than a structured error response if the execution framework does not wrap body() in a try/catch

Confidence Score: 4/5

Safe to merge after addressing the throw-in-body() issue in update_flag.ts, which can cause an unhandled exception when no update fields are provided.

One P1 finding remains: update_flag.ts throws inside body() when all optional update fields are empty, which is inconsistent with every other tool's error-handling pattern and may surface as an unhandled exception. All other tools are clean and well-structured.

apps/sim/tools/launchdarkly/update_flag.ts — the throw inside body() at lines 2603-2607 should be replaced with structured error handling.

Important Files Changed

Filename	Overview
apps/sim/tools/launchdarkly/update_flag.ts	Implements semantic-patch update for flag metadata; throws an Error inside body() when no update fields are provided, which may bypass structured error handling.
apps/sim/blocks/blocks/launchdarkly.ts	Block config with conditional fields, proper string-to-boolean coercions for toggle/archive/temporary, and correct AuthMode.ApiKey; no issues found.
apps/sim/tools/launchdarkly/toggle_flag.ts	Correctly uses semantic-patch Content-Type and reads the on state back from the specific environment key in the response.
apps/sim/tools/launchdarkly/types.ts	Clean shared output-property constants and TypeScript interfaces covering all 12 tools; no issues found.
apps/sim/tools/launchdarkly/get_flag_status.ts	Correct URL structure and response mapping (data.default → defaultVal); no issues found.

Sequence Diagram

sequenceDiagram
    participant User
    participant Block as LaunchDarkly Block
    participant Framework as Tool Framework
    participant LD as LaunchDarkly API v2

    User->>Block: Select operation + fill params
    Block->>Framework: tool: launchdarkly_{operation}, params coerced
    Framework->>Framework: call request.url(params)
    Framework->>Framework: call request.headers(params)
    Framework->>Framework: call request.body(params)
    Note over Framework: ⚠️ update_flag throws here if no instructions built
    Framework->>LD: HTTP request (GET/POST/PATCH/DELETE)
    LD-->>Framework: JSON response
    Framework->>Framework: call transformResponse(response, params)
    Framework-->>Block: { success, output } or { success: false, error }
    Block-->>User: Structured output

Loading

Comments Outside Diff (1)

1. apps/sim/tools/launchdarkly/update_flag.ts, line 2603-2607 (link)

   throw inside body() bypasses structured error handling

   When none of the optional update fields (updateName, updateDescription, addTags, removeTags, archive) are provided, the code builds an empty instructions array and then throws inside the body() function. This is the only tool in the entire PR that throws in a request builder function — every other tool returns a graceful error via transformResponse. If the tool-execution framework does not wrap body() in a try/catch, this will surface as an unhandled exception instead of a structured { success: false, error: "…" } response.

   All update fields are optional in the block UI, so a user can easily reach this path. Move the guard to transformResponse or add an explicit pre-flight check in the params transformation in launchdarkly.ts, rather than throwing in the request builder.

_{Reviews (2): Last reviewed commit: "lint" | Re-trigger Greptile}

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR