Share via

Azure Functions extension bundle not found for ranges starting above 4.32.0 despite 4.35.0 being a valid GA release

Leo Liu 60 Reputation points
2026-05-26T00:53:34.3533333+00:00

Hi,

We are developing a Durable Functions app with Durable Task Scheduler (DTS). Following the quickstart docs, we set up host.json with:

{
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[4.32.0, 5.0.0)"
  }
}

Following the releases https://github.com/Azure/azure-functions-extension-bundles/releases, since 4.35.0 is the latest stable GA release, we wanted to pin to it exactly:

{
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[4.35.0, 4.36.0)"
  }
}

However, the function app fails at startup with:

Bundle version matching the range [4.35.0, 4.36.0) was not found.

We also tested [4.33.0, 4.36.0) and [4.34.0, 4.36.0) — both fail with the same error. Strangely, [4.32.0, 4.36.0) works without issue.

This is confusing because 4.35.0 is listed as a GA release on the azure-functions-extension-bundles releases page, and 4.32.0 is clearly within the working range. Why would 4.35.0 be resolvable when the range starts at 4.32.0 but not when it starts at 4.33.0 or higher?

Azure Functions
Azure Functions

An Azure service that provides an event-driven serverless compute platform.

0 comments

Answer accepted by question author

Vinodh247-1375 42,941 Reputation points Volunteer Moderator
2026-05-26T00:56:36.3533333+00:00

Hi ,

Thanks for reaching out to Microsoft Q&A.

This is a known quirk in how azure Functions resolves extension bundles, not a versioning mistake on your side. The runtime does not resolve versions directly from the GitHub releases list; it only considers bundles that are actually published to the extension bundle CDN/feed used by the Functions host. In your case, versions like 4.33.0-4.35.0 are tagged as GA on GitHub but were either not propagated, not indexed correctly, or partially rolled out in the bundle feed.

When you specify [4.32.0, 4.36.0), the resolver is free to pick the highest available version in the feed (which may still map internally to a valid published bundle, even if intermediate versions are missing). But when you constrain the lower bound to [4.33.0, …) or higher, the resolver fails because it cannot find any bundle in the feed that satisfies that exact starting range, even though 4.35.0 exists in GitHub.

Note: do not pin to narrow ranges unless you have verified availability in the bundle feed. Use a broader range like [4.32.0, 5.0.0) or explicitly test a working range; GitHub releases alone are not a reliable indicator of what the Functions runtime can resolve.

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

Was this answer helpful?

1 person found this answer helpful.
0 comments

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Rakesh Mishra 9,505 Reputation points Microsoft External Staff Moderator
    2026-05-26T01:08:34+00:00

    Hello Leo,

    Thank you for reaching out to the Microsoft Q&A community. The behavior you are encountering is expected.

    The root cause of this issue is that the Azure Functions host resolves and downloads extension bundles from the live Azure Functions CDN feed, not directly from the GitHub releases page. Even if a release tag (like v4.35.0) is cut in the GitHub repository, it may not be immediately published to the live extension bundle feed that the Functions runtime utilizes, or it might be treated as an unreleased/preview version.

    When you configure your host.json with a tight version interval like [4.33.0, 4.36.0) or [4.35.0, 4.36.0), the runtime expects to find a published bundle on the CDN that satisfies that minimum requirement. Since those specific micro-versions haven't been published to the live feed, the runtime fails to find a valid package and throws the "Extension bundle not found" error.

    According to the official Microsoft documentation on Azure Functions Extension Bundles:

    "The version range of the bundle to install. The Azure Functions runtime always chooses the maximum permissible version that the version range or interval defines."

    To ensure maximum compatibility and avoid manual pinning issues, the documentation states:

    "For optimal supportability and reliability, you should upgrade to bundle version 4.x... By default, extension bundles are defined via version ranges, which guarantees that the latest minor bundle version is used."

    Why [4.32.0, 4.36.0) works without issue: Here is exactly why [4.32.0, 4.36.0) works, while ranges starting with higher micro-versions fail:

    • How the logic works: When you define a range, the Functions host queries the live CDN for all available published bundles and selects the highest available version that satisfies your mathematical interval.
    • Why [4.32.0, 4.36.0) succeeds: The square bracket [ means inclusive. So, this range tells the host: "Find me the highest bundle on the CDN that is greater than or equal to 4.32.0, but strictly less than 4.36.0." Because 4.32.0 is currently published and live on the CDN, it satisfies the minimum boundary of your range. The host successfully pulls 4.32.0 and starts up.
    • Why [4.33.0, 4.36.0) or [4.35.0, ...) fails: This tells the host: "Find me a bundle on the CDN that is greater than or equal to 4.33.0 (or 4.35.0)." Because the highest version currently published on the CDN is 4.32.0, there is no package available that meets your minimum requirement, causing the resolution to fail.

    Essentially, your [4.32.0, 4.36.0) range is succeeding because it is happily falling back to the 4.32.0 bundle.

    Resolution: To resolve this issue and keep your application stable without breaking when new GitHub tags are made, it is highly recommended to use the standard 4.x version range. Please update your host.json to the following:

    {
  "version": "2.0",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[4.0.0, 5.0.0)"
  }
}

    Using this notation instructs the Functions host to automatically fetch the highest verified and available 4.x bundle from the CDN.

    Hope this helps! Let us know in comments if you have any follow-up questions.

    Note: This response is drafted with the help of AI systems.

    Was this answer helpful?

  2. AI answer

    2026-05-26T00:53:50.1566667+00:00

    The behavior comes from how Azure Functions resolves extension bundles and from the recommended way to specify bundle versions, not from Durable Functions or DTS specifically.

    Key points from the documented behavior:

    1. Extension bundles are meant to be referenced by a broad version range, not pinned to a specific minor version.
      • The documentation consistently uses: 
             {
       "version": "2.0",
       "extensionBundle": {
         "id": "Microsoft.Azure.Functions.ExtensionBundle",
         "version": "[4.0.0, 5.0.0)"
       }
     }
      • Or equivalently [4.*, 5.0.0).
      • This tells the Functions host: “use the latest available 4.x bundle,” and the runtime chooses the maximum permissible version in that range.
    2. The supported ranges for the 4.x bundle are explicitly documented and are coarse-grained, not per‑minor‑version:
      • For 4.x the documented, supported range is:
        • [4.0.0, 5.0.0) or [4.*, 5.0.0)
      • Other ranges (like [4.35.0, 4.36.0)) are not documented or guaranteed to resolve, even if a GitHub release exists.
    3. Why [4.32.0, 4.36.0) works but [4.33.0, 4.36.0) fails:
      • The runtime does not resolve bundles by scanning every GitHub tag; it resolves against bundle versions that are actually published and available to the Functions host.
      • The documentation only guarantees that ranges like [4.0.0, 5.0.0) (or [4.*, 5.0.0)) will work and that the host will choose the maximum permissible version in that range.
      • When using a custom, narrow range such as [4.35.0, 4.36.0), the host must find a bundle whose version falls within that exact interval. If no bundle matching that interval is available from the bundle feed, the host reports:

        Bundle version matching the range [4.35.0, 4.36.0) was not found.

      • The fact that [4.32.0, 4.36.0) works simply means that there is at least one bundle version ≥ 4.32.0 and < 4.36.0 that the host can resolve. It does not guarantee that the host can resolve a bundle when the lower bound is raised to 4.33.0 or 4.35.0.
    4. Recommended configuration for Durable Functions and DTS:
      • For non-.NET apps (JavaScript, Python, Java, PowerShell), the guidance is to ensure the extensionBundle range includes the latest 4.x bundle, using the standard range: 
             {
       "version": "2.0",
       "extensionBundle": {
         "id": "Microsoft.Azure.Functions.ExtensionBundle",
         "version": "[4.0.0, 5.0.0)"
       }
     }
      • Or, as also documented: 
             {
       "version": "2.0",
       "extensionBundle": {
         "id": "Microsoft.Azure.Functions.ExtensionBundle",
         "version": "[4.*, 5.0.0)"
       }
     }
      • This keeps the app on the latest 4.x bundle and avoids resolution issues with narrow custom ranges.
    5. If a specific Durable Functions extension version is required:
      • The documented approach is not to pin the bundle to a narrow interval, but instead to:
        1. Remove the extensionBundle section from host.json.
        2. Use func extensions install (and optionally -p/-v) to install the exact extension version needed.
      • This is explicitly called out as a manual, advanced scenario and comes with the warning that it disables automatic bundle updates and can introduce compatibility issues.

    In summary, the error occurs because only certain version ranges are guaranteed to resolve against the published bundle feed. Narrow ranges like [4.35.0, 4.36.0) are not supported, even if GitHub shows a 4.35.0 release. The supported and recommended configuration is to use the documented 4.x range ([4.0.0, 5.0.0) or [4.*, 5.0.0)), or to disable bundles and manually install extensions when an exact version is required.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.