CloudRunner not persisting returned variables between Function and Display blocks

MindStudio IDE Bug Reports
1

Description of the issue

When using CloudRunner in a MindStudio project, return values from a Function block (Run Function) are not being persisted into the workflow, resulting in "undefined" or "empty message" in subsequent Display Content blocks.

The function executes successfully — console logs confirm all logic completes normally — but the values returned (e.g., configSummary or configSummaryVar) never appear in the workflow state or downstream blocks.

This persists across all variable-name configurations (configSummary, configSummaryVar, output.configSummary, etc.), and even after:

  • Re-creating the Function block,

  • Removing all Reference Data fields,

  • Embedding static tables directly in code,

  • Using simplified string returns and single-object returns,

  • Confirming that console output shows the data being returned.

In the run logs:

  • Function completes normally (✅ Product selection complete.).

  • “Resolved function configuration object” shows correct schema.

  • The Display Content block then logs:

    Sending message: "{{configSummary}}"
Sent message: "undefined"

    proving the returned data isn’t being written to workflow memory.

Intended behavior

CloudRunner should persist all values explicitly returned by a Function block (whose keys match the block’s Output Variable names) so that subsequent blocks (e.g., Display Content) can access them via {{variableName}}.

AI Agent link

Attachments

  • Run log JSON (mindstudio-run-be0f5c99…, mindstudio-run-ec666120…, etc.)
# Filename (as uploaded) What it demonstrates
:one: mindstudio-run-26eabdc6-4f8c-4ffd-a80e-4aff05d9f288.log.json Early undefined — before table parsing fix; proves function executed but variables dropped.
:two: mindstudio-run-c7921420-4de5-485e-8b6c-4cbd6716d343.log.json Shows CloudRunner flattening [object Object] in Reference Data inputs.
:three: mindstudio-run-648b72a2-6d8c-42ef-ba77-32e184c2c6e4.log.json Demonstrates schema still injecting empty tables (burnerTable:"" etc.).
:four: mindstudio-run-7ce39e13-7441-416e-ba9b-df0f44123c0e.log.json Confirms successful internal logic but empty outputs returned.
:five: mindstudio-run-00d926ec-46b3-4c47-ba60-69471000ae8d.log.json Valid data inside function; undefined output downstream.
:six: mindstudio-run-abb7234d-8283-4f9f-baf4-d745724c9c76.log.json Shows return object exists yet still lost when passed to Display Content.
:seven: mindstudio-run-f0ab77b2-233f-4dbb-a734-3d73afe42570.log.json Logs “Empty message” while function clearly returns data.
:eight: mindstudio-run-e86fdd58-b77f-44fe-a69a-3c7221312a8c.log.json Confirms CloudRunner executes correctly but loses output serialization.
:nine: mindstudio-run-a357955e-b0e6-4eab-857e-7e56a857fefe.log.json First trace showing schema mismatch between expected vs returned variables.
:ten: mindstudio-run-135664c1-0226-4803-8938-7ba14346c1f4.log.json “Empty message” variant; function completes cleanly but returns vanish.
11️⃣ mindstudio-run-2f4eac12-db2d-44dc-8509-2404538f3871.log.json Confirms inline tables ignored because CloudRunner injects empty schema keys.
12️⃣ mindstudio-run-ec666120-2367-4f90-aa15-775e258eb61f.log.json Definitive proof: runtime executes successfully; return object dropped.
13️⃣ mindstudio-run-be0f5c99-aab6-41d2-81aa-322435efffb8.log.json Most recent run — shows proper console logs but {{configSummary}} → undefined.

Notes

  • Runtime: CloudRunner

  • Behavior confirmed across multiple function schema resets and variable mappings.

  • Same logic works in Sandbox or local execution, so this appears to be a CloudRunner serialization or variable-binding issue.

2

Hello @rdearmas,

Thanks for the post.

Could you Publish the Agent and share the remix link so we can take a closer look?

Also, could you clarify your use case and what you’d like the Agent to do?

5

Hello @rdearmas,

Thanks for sharing the remix link!

You are correct, data doesn’t persist across different Custom Functions in a MindStudio Agent unless you write it to ai.vars.

Here’s what’s happening in your Agent:
CloudRunner executes your function and you see logs, but the object you return doesn’t automatically turn into {{variables}} the next block can use. Display Content expects {{configSummary}} to be present in ai.vars.configSummary. Since it isn’t set, it shows undefined.

1. Persist values with ai.vars

Replace your current return in “initializeReferenceTables” with:

  const burnerTableJson  = JSON.stringify(burnerTable);
  const controlTableJson = JSON.stringify(controlTable);
  const mediaTableJson   = JSON.stringify(mediaTable);

  if (typeof ai !== 'undefined' && ai && ai.vars) {
    ai.vars.burnerTable  = burnerTableJson;
    ai.vars.controlTable = controlTableJson;
    ai.vars.mediaTable   = mediaTableJson;
  }

  return {
    burnerTable: burnerTableJson,
    controlTable: controlTableJson,
    mediaTable: mediaTableJson
  };
}

And do the same in the “selectProducts” function:

if (typeof ai !== 'undefined' && ai && ai.vars) {
  ai.vars.configResult  = JSON.stringify(configResult);
  ai.vars.configSummary = configSummary;
}
return {
  configResult: JSON.stringify(configResult),
  configSummary
};

2. Reference variables in the Process Selection block configuration
Make sure the block config references the outputs from the first function:

image
image632×323 30.5 KB

6

Hi Alex,

Thanks for the detailed explanation — we actually tried this exact approach multiple times.

Here’s what happens in practice:

  1. When we use ai.vars inside CloudRunner / Virtual Machine mode, the values don’t persist or propagate downstream.

    • The function logs show that ai.vars exists (so no runtime error), but the values never appear in the next block.

    • The result is still undefined or “Empty Message” in the Display Content block.

  2. When we switch to Sandbox, the same code and logic work correctly — but Sandbox doesn’t support external HTTP calls or production execution, so it’s not viable for deployment.

  3. We also tested returning values explicitly (without relying on ai.vars), for example:

    return { configResult, configSummary };

    but the returned object still isn’t available to the next block in CloudRunner.

So effectively, CloudRunner ignores both ai.vars persistence and direct return {} outputs, breaking the chain between Custom Functions.
That’s why our Agent consistently fails at runtime, even though the functions themselves execute successfully and log expected data.

Our expectation is that explicit return values should be usable as inputs for downstream blocks — the same way they are in Sandbox or MindStudio’s LLM output blocks.

Could you please confirm whether this is a known CloudRunner limitation or bug, and whether there’s a roadmap fix for it?

Attached is the full Run Log (mindstudio-run-160efa1b-aa9a-4d11-b968-11804cf32f08.log.json) that clearly show the returned data and missing variable propagation.

Thanks for your help with this.

(Attachment mindstudio-run-160efa1b-aa9a-4d11-b968-11804cf32f08.log.json is missing)

7

I don’t know if my email response went through, so I will paste it here again.

Hi Alex,

Thanks for the detailed explanation — we actually tried this exact approach multiple times.

Here’s what happens in practice:

  1. When we use ai.vars inside CloudRunner / Virtual Machine mode, the values don’t persist or propagate downstream.

    • The function logs show that ai.vars exists (so no runtime error), but the values never appear in the next block.

    • The result is still undefined or “Empty Message” in the Display Content block.

  2. When we switch to Sandbox, the same code and logic work correctly — but Sandbox doesn’t support external HTTP calls or production execution, so it’s not viable for deployment.

  3. We also tested returning values explicitly (without relying on ai.vars), for example:

    return { configResult, configSummary };

    but the returned object still isn’t available to the next block in CloudRunner.

So effectively, CloudRunner ignores both ai.vars persistence and direct return {} outputs, breaking the chain between Custom Functions.
That’s why our Agent consistently fails at runtime, even though the functions themselves execute successfully and log expected data.

Our expectation is that explicit return values should be usable as inputs for downstream blocks — the same way they are in Sandbox or MindStudio’s LLM output blocks.

Could you please confirm whether this is a known CloudRunner limitation or bug, and whether there’s a roadmap fix for it?

Here’s a link to a Dropbox Folder that contains error logs:

Date Log File Name Key Evidence
Oct 23, 2025 mindstudio-run-abb7234d-8283-4f9f-baf4-d745724c9c76.log.json Explicitly implemented ai.vars.burnerTable, ai.vars.controlTable, and ai.vars.mediaTable in initializeReferenceTables. Despite this, the next block (selectProducts) received empty data and output “Empty Message.”
Oct 23, 2025 mindstudio-run-f0ab77b2-233f-4dbb-a734-3d73afe42570.log.json ai.vars.configResult and ai.vars.configSummary were written successfully within selectProducts, confirmed in logs, but Display Content still rendered as “Empty Message.”
Oct 23, 2025 mindstudio-run-e86fdd58-b77f-44fe-a69a-3c7221312a8c.log.json Re-test after confirming correct syntax for both initialize and select functions. Log shows ai.vars objects exist and store JSON strings, yet output remains undefined.
Oct 23, 2025 mindstudio-run-a357955e-b0e6-4eab-857e-7e56a857fefe.log.json Final “ai.vars version” test — both functions return objects and write to ai.vars; CloudRunner accepts execution but downstream block still cannot read any ai.vars variables.
8

Hi @rdearmas,

Thanks for the quick reply!

Here’s a remix link to a sample Agent that uses two Custom Functions in a VM environment:
https://app.mindstudio.ai/agents/rdearmas–sample-agent-with-two-custom-functions-102f3d3e/remix

Here’s the setup:

  1. Display Content block saves a story to a variable
  2. The first function trims it to 100 characters
  3. The trimmed version is displayed
  4. The second function turns it into a .txt file
  5. The link to the file is displayed

Hope this helps!

9

Hi Alex,

Thanks for sending the sample Agent — I reviewed it, and it does help illustrate how ai.vars works within a single execution context.

However, my use case is slightly different and reproduces a distinct issue:
our Agent uses two Custom Functions in separate blocks (initializeReferenceTables and selectProducts) running in CloudRunner / VM mode.
When ai.vars values are set in the first function, they’re not available in the second — even though the log confirms they were written successfully.

The difference is that each Custom Function in CloudRunner appears to run inside its own containerized VM, resetting ai.vars to an empty object each time.
That means ai.vars persistence only works within one block chain, not across multiple Custom Functions — unlike the behavior in Sandbox.

In short:

  • :white_check_mark: The sample works because both functions run in the same context.

  • :cross_mark: Our workflow fails because each Custom Function block gets a fresh ai.vars object in CloudRunner.

Could you confirm whether CloudRunner is designed to isolate ai.vars per function instance?
If so, is there any supported method to pass data objects between Custom Functions in CloudRunner (for example, through explicit return objects or serialized JSON variables)?

We’ve verified this behavior in multiple run logs (e.g. mindstudio-run-abb7234d-8283-4f9f-baf4-d745724c9c76.log.json, mindstudio-run-a357955e-b0e6-4eab-857e-7e56a857fefe.log.json).

If this is not possible in Mindstudio, please just let me know.

Thanks

10

Hi @rdearmas,

When you mention both functions running “in the same context”, could you clarify what you mean by that? The sample Agent also uses two separate Custom Function blocks running in the VM environment, so I’d like to understand what makes the context different in your case.

To answer your questions:

Yes, that’s correct.

You can assign values to variables defined in the block configurations using ai.vars. In your case, you can replace the return function with the snippet below to make sure the values are assigned and accessible in the following blocks with {{burnerTable}} and other defined variables:

  ai.vars[ai.config.burnerTableVar] = JSON.stringify(burnerTable);
  ai.vars[ai.config.controlTableVar] = JSON.stringify(controlTable);
  ai.vars[ai.config.mediaTableVar] = JSON.stringify(mediaTable);