Share via

Custom function cells permanently stuck in "Calculating" state when `worksheet.calculate(true)` is called before taskpane is opened.

Rahul Gimhavanekar 0 Reputation points
2026-04-24T10:31:39.5766667+00:00

We have an Excel Add-in using a Shared Runtime. Our custom functions (@customfunction) are batched and resolved via fetch() API calls. We have a ribbon button (ExecuteFunction) that calls worksheet.calculate(true) to force-recalculate the active worksheet.

Observed behavior:
When a user clicks the ribbon button without the taskpane having been opened first, custom function cells enter a "Calculating..." state and never resolve — they remain stuck indefinitely. No error is shown in the cell. When the user opens the taskpane first and then clicks the same ribbon button, the custom functions recalculate and resolve correctly.

Expected behavior:
Custom functions should resolve regardless of whether the taskpane has been opened prior to triggering recalculation.

Questions for Microsoft:

  1. In a Shared Runtime, is there any difference in the custom function execution environment depending on whether the taskpane has been loaded? Does opening the taskpane perform any runtime initialization that is required for custom functions to resolve?
  2. When worksheet.calculate(true) is called and Excel re-invokes a custom function, does Excel abandon/cancel the previously pending invocation (and its associated promise), or does it create a new invocation while the old promise remains pending in the JS runtime?
  3. Is there a known race condition or lifecycle issue where custom functions triggered by ExecuteFunction ribbon commands (before taskpane initialization) can result in permanently unresolved cells?
  4. Is there any Office.js API or event we can listen to in order to detect when a custom function cell is stuck, so we can programmatically re-trigger recalculation?

Environment:

  • Office 365 (Excel on Windows)
  • Shared Runtime (<Runtime lifetime="long">)
  • Custom Functions registered via @customfunction JSDoc annotation
  • Manifest type: XML
Microsoft 365 and Office | Development | Office JavaScript API
0 comments No comments

2 answers

Sort by: Most helpful
  1. Dora-T 14,950 Reputation points Microsoft External Staff Moderator
    2026-04-24T12:17:41.95+00:00

    Hi Rahul Gimhavanekar

    Thank you for reaching out to the Microsoft Q&A Forum and for sharing the detailed scenario.

    Based on my research and similar cases, there is currently no official Microsoft documentation that directly explains this specific behavior. However, here are some relevant points that may help clarify your questions:

    1. Shared Runtime vs taskpane initialization

    In a Shared Runtime, custom functions, ribbon commands, and the taskpane are designed to run within the same JavaScript runtime. However, there is no documented guarantee that the runtime is fully initialized before the taskpane is opened. In practice, some cases show that custom functions may not resolve until the taskpane is loaded or another UI interaction occurs.

    Reference: Configure your Office Add-in to use a shared runtime - Office Add-ins | Microsoft Learn

    1. Behavior of worksheet.calculate(true)

    There is no official documentation describing how Excel handles existing custom function invocations when recalculation is triggered. It is unclear whether previous invocations are canceled or continue running while new ones are issued. Custom functions are asynchronous, but their lifecycle in this context is not fully documented.

    1. Possible lifecycle or timing issue

    Although not formally documented, similar issues have been reported where custom functions remain in a “Calculating…” or #BUSY! state until another interaction (such as opening the taskpane) occurs.  This suggests the behavior may be related to runtime initialization timing rather than the function logic itself.

    Reference: Excel custom functions in shared runtime display #BUSY! indefinitely until another unrelated action…

    1. Detecting stuck custom functions

    There is currently no Office.js API or event to detect when a custom function is stuck in a calculating state. Existing worksheet events do not provide visibility into unresolved custom function executions.

    Reference: Work with Events using the Excel JavaScript API - Office Add-ins | Microsoft Learn

    Please note that as a moderator, this is a public peer-to-peer community forum. While we can share guidance and known behaviors, we do not have access to backend systems or tools to investigate runtime-level issues in depth.

    If you need deeper insight into runtime behavior, I recommend posting a new thread on GitHub, where engineers and the Office.js community may be able to provide more targeted guidance.

    Reference: Participating in a discussion - GitHub Docs. 

    Thank you for your patience and understanding.


    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    Was this answer helpful?


  2. AI answer

    2026-04-24T10:32:16.8433333+00:00

    The behavior described cannot be fully answered from the available information. The context only provides general guidance and troubleshooting for custom functions, not the specific shared-runtime lifecycle and worksheet.calculate(true) interaction being asked about.

    Relevant points from the context that may help investigation:

    1. Custom functions and Excel JavaScript APIs
    • Custom functions can call Excel JavaScript APIs, but they must not change cells outside the cell running the custom function or modify the Excel environment. Doing so can cause poor performance, timeouts, or infinite loops.
    • Custom function calculations should not run while an Excel recalculation is taking place, because this can create unpredictable results.

    This suggests that any pattern where a ribbon command forces recalculation (worksheet.calculate(true)) while custom functions are already in progress can lead to undefined or unstable behavior, including cells not resolving.

    1. Troubleshooting custom functions
    • Runtime logging can be enabled in Office on Windows to capture errors and console.log output into a log file. This can reveal manifest issues, runtime conditions, or installation problems.
    • Excel custom functions only surface a limited set of error values (#NULL!, #DIV/0!, #VALUE!, #REF!, #NAME?, #NUM!, #N/A, #BUSY!). If cells remain in a perpetual “Calculating…” state without an error, runtime logging is the primary way to see what is happening in the background.
    1. Calculation behavior and #BUSY
    • For Excel JavaScript API add-in custom functions, users see #BUSY! until a result is returned. This is the expected behavior when a function is pending.
    • If a function never resolves, the underlying promise is likely never settled (resolved or rejected). The context does not document any built-in mechanism or event to detect “stuck” custom function cells beyond the visible #BUSY! or logging.
    1. Known limitations and lifecycle hints
    • The documentation explicitly warns that custom function calculations should not run while an Excel recalculation is taking place, because it creates unpredictable results. This aligns with the scenario where a ribbon button forces recalculation while custom functions are already active.
    • There is no documented API in the provided context that:
      • Differentiates the custom function execution environment based on whether the taskpane has been opened.
      • Describes how Excel cancels or replaces pending custom function invocations when Application.Calculate or worksheet.calculate(true) is called.
      • Exposes an event or Office.js API to detect that a custom function cell is “stuck” and programmatically re-trigger recalculation.

    Given the constraints of the context, the following actions are supported by documentation and can be used to investigate or mitigate:

    • Enable runtime logging to capture what happens when the ribbon button is clicked before the taskpane is opened, and compare it to the case where the taskpane is opened first.
    • Ensure that custom functions do not perform disallowed operations (such as writing to other cells or changing environment options) when triggered by recalculation.
    • Use Excel’s built-in recalculation shortcuts (for example, Application.Calculate in VBA or the equivalent keyboard shortcuts) as a comparison to see whether the behavior is specific to the ribbon command or to the shared runtime initialization.
    • If the behavior appears to be a product issue, report it using Excel’s feedback mechanism (File → Feedback → Send a Frown) or by filing an issue in the custom functions GitHub repository, including logs from runtime logging and a minimal repro.

    The context does not provide direct answers to:

    • Whether opening the taskpane performs required initialization for custom functions in a shared runtime.
    • Whether Excel cancels or reuses pending custom function promises when worksheet.calculate(true) is invoked.
    • Any documented race condition specific to ribbon-triggered recalculation before taskpane initialization.
    • Any Office.js event or API to detect and recover from “stuck” custom function cells.

    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.