Skip to content

getPlatformProxy() fails if you have workflow defined #9402

Closed
Bug
Closed
getPlatformProxy() fails if you have workflow defined#9402
Bug
Labels
quick-winPotentially easy/straightforward issue to tackle

Description

@kevinsimper
kevinsimper
opened on May 29, 2025

What versions & operating system are you using?

wrangler 4.17.0

Please provide a link to a minimal reproduction

No response

Describe the Bug

const platform = await getPlatformProxy();

Fails if you have workflows defined in wrangler.jsonc, but there is no way to give it as input.

Commeting workflows out makes it work, or making a minimal "wranglercli.jsonc"

Please provide any relevant error logs

$ npx tsx src/lib/readcloudflarecli.ts
Using vars defined in .dev.vars
Worker "workflows:workflows-starter-dev"'s binding "USER_WORKFLOW" refers to service "core:user:[PROJECT_NAME]" with a named
entrypoint "MyWorkflow", but "core:user:[PROJECT_NAME]" has no such named entrypoint.
[PROJECT_PATH]/node_modules/wrangler/node_modules/miniflare/dist/src/index.js:16770
      throw new MiniflareCoreError(
            ^

MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start. There is likely additional logging
output above.
    at _Miniflare.#assembleAndUpdateConfig
([PROJECT_PATH]/node_modules/wrangler/node_modules/miniflare/src/index.ts:1498:10)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)

Activity

  1. kevinsimper
    added the
    Bug
    issue type on May 29, 2025
  2. kevinsimper
    added
    bug
    on May 29, 2025
  3. lrapoport-cf
    added this to workers-sdkon Jul 15, 2025
  4. github-project-automation
    moved this to Untriaged in workers-sdkon Jul 15, 2025
  5. petebacondarwin
    changed the title [-]getPlatformProxy() fails if you have workflow defines[/-] [+]getPlatformProxy() fails if you have workflow defined[/+] on Jul 28, 2025

  6. petebacondarwin commented on Jul 28, 2025

    @petebacondarwin
    petebacondarwin
    on Jul 28, 2025
    Contributor

    Yes this is a bug. Similar to Durable Objects, Workflows contain local code, that is not supported by getPlatformProxy.
    In the case of DOs we just put up a warning and don't crash. See https://github.com/cloudflare/workers-sdk/blob/dab1059dd2a810ce1b1006f6c327f025f3b9a56a/packages/wrangler/src/api/integrations/platform/index.ts#L210-L222

    We should do the same for Workflows.

  7. petebacondarwin
    moved this from Untriaged to Backlog in workers-sdkon Jul 28, 2025
  8. petebacondarwin
    added
    quick-winPotentially easy/straightforward issue to tackle
    on Jul 28, 2025
  9. petebacondarwin
    added a commit that references this issue on Jul 31, 2025

    fix: handle workflow bindings in getPlatformProxy()

    765a123
  10. petebacondarwin
    self-assigned this
    on Aug 2, 2025

  11. dan-massey commented on Sep 15, 2025

    @dan-massey
    dan-massey
    on Sep 15, 2025

    @petebacondarwin thanks for picking up this issue, do you know when it might be fixed?

  12. petebacondarwin commented on Sep 16, 2025

    @petebacondarwin
    petebacondarwin
    on Sep 16, 2025
    Contributor

    I can have a look next week.

  13. zocario commented on Sep 23, 2025

    @zocario
    zocario
    on Sep 23, 2025

    Hi 👋 I'm seeing this issue with a workflow defined in my wrangler file and running an Nextjs app with opennextjs-cloudflare.

    Running locally or deploying (with wrangler deploy) is only possible if the workflow is defined in each environment but not at the global level of the wrangler.jsonc file. The command opennextjs-cloudflare deploy is failing, even with this trick (taken from #7414 (comment)).

    For info the stack trace of the error when deploying:

    Worker "workflows:report-reminders-preview"'s binding "USER_WORKFLOW" refers to service "core:user:open-next-preview" with a named entrypoint "ReportRemindersWorkflow", but "core:user:open-next-preview" has no such named entrypoint.
opennextjs-cloudflare deploy

MiniflareCoreError [ERR_RUNTIME_FAILURE]: The Workers runtime failed to start. There is likely additional logging output above.
    at #assembleAndUpdateConfig (/home/runner/work/ThereApp/ThereApp/node_modules/miniflare/dist/src/index.js:61711:13)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async Mutex.runWith (/home/runner/work/ThereApp/ThereApp/node_modules/miniflare/dist/src/index.js:38854:48)
    at async #waitForReady (/home/runner/work/ThereApp/ThereApp/node_modules/miniflare/dist/src/index.js:61798:5)
    at async _Miniflare._getProxyClient (/home/runner/work/ThereApp/ThereApp/node_modules/miniflare/dist/src/index.js:62017:5)
    at async _Miniflare.getBindings (/home/runner/work/ThereApp/ThereApp/node_modules/miniflare/dist/src/index.js:62036:25)
    at async getPlatformProxy (/home/runner/work/ThereApp/ThereApp/node_modules/wrangler/wrangler-dist/cli.js:247372:20)
    at async getEnvFromPlatformProxy (file:///home/runner/work/ThereApp/ThereApp/node_modules/@opennextjs/cloudflare/dist/cli/commands/helpers.js:10:19)
    at async deployCommand (file:///home/runner/work/ThereApp/ThereApp/node_modules/@opennextjs/cloudflare/dist/cli/commands/deploy.js:17:21) {
  code: 'ERR_RUNTIME_FAILURE',
  cause: undefined
}

    @petebacondarwin I think it is the same cause as this issue, do you think it'll be solved by your ongoing fix on this SDK or should I open an other issue on the OpenNext repo?

  14. petebacondarwin commented on Sep 23, 2025

    @petebacondarwin
    petebacondarwin
    on Sep 23, 2025
    Contributor

    You are suffering from the same problem, I'm afraid.
    The fix is proving to be a little fiddly and I keep getting distracted by more pressing matters.

  15. zocario commented on Sep 23, 2025

    @zocario
    zocario
    on Sep 23, 2025

    You are suffering from the same problem, I'm afraid. The fix is proving to be a little fiddly and I keep getting distracted by more pressing matters.

    Thanks for the answer 🙏 Do you have an estimated timeline for delivering the fix? We’re experiencing performance issues in our app and need to use the cache/deploy commands from OpenNext to help mitigate them.

  16. Antoine4011 commented on Sep 25, 2025

    @Antoine4011
    Antoine4011
    on Sep 25, 2025

    Hey @petebacondarwin, we're running into the same issue. This prevents us from deploying our app. Thank you for your help 🙏

  17. petebacondarwin commented on Sep 25, 2025

    @petebacondarwin
    petebacondarwin
    on Sep 25, 2025
    Contributor

    OK, to expedite a fix, I am going to change my PR to filter out "all" Workflows, since remote ones are also not supported right now anyway. This should unblock everyone on this issue, sincer will effectively just ignore all Workflow bindings when running getPlatformProxy()

  18. dan-massey commented on Oct 23, 2025

    @dan-massey
    dan-massey
    on Oct 23, 2025

    Hi @petebacondarwin do you have any updates on this issue? Thanks!

  19. petebacondarwin commented on Oct 23, 2025

    @petebacondarwin
    petebacondarwin
    on Oct 23, 2025
    Contributor

    Sorry this fell off my radar. I'll take a look tomorrow.

  20. petebacondarwin
    removed their assignment
    on Dec 17, 2025

  21. penalosa commented on Feb 4, 2026

    @penalosa
    penalosa
    on Feb 4, 2026
    Contributor

    This was resolved in #10112, released in wrangler@4.40.3

  22. penalosa
    closed this as completedon Feb 4, 2026
  23. github-project-automation
    moved this from Backlog to Done in workers-sdkon Feb 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    quick-winPotentially easy/straightforward issue to tackle

    Type

    Bug

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions