SBut confusingly, the output property of the Binding InstanceStatus contains the step results, not the workflow output.
DS
it should be an unknown there - i'll look into it but I think it's an openapi 3.0 limitationDSS
D looking forward to it! Good idea to keep the step outputs available for debugging locally
A
AAA
AA
await step.sleep('wait 24 hours', '24 hours'), which have been stuck in the "running" phase for many hours (30+)AWaitingRunning, and counting towards the 100 concurrency limitS
S
@cloudflare/worker-types and should be on WorkflowEvent.instanceId S
AAAA
S
C
@Seekerdasbatatas thanks for keeping updates coming our way and improving the product each day according to the user needs. you guys are the best!
Wnpx wrangler workflow targets production api. Do I need to setup a local worker to call my local workflow?
M
FF
HA
wrangler types --experimental-include-runtime
Denv.WORKFLOW.get(id).status().output (something like a sort of kv?) or is it something one shouldn't rely on (e.g. expires after some time)?DRetention limit for completed Workflow state: 3 days; 30 days
Aevent.params (e.g. https://developers.cloudflare.com/workflows/get-started/guide/) whereas I now think it's event.payload (changing this fixed it for me so guessing event.params was old?)
WSerialized RPC arguments or return values are limited to 1MiB errorM
B
E
O
YY
step_name be added anywhere in future in status ?step_name along with the data as a workaround
ᴀMᴀMCMCMC
await step.sleep('wait 24 hours', '24 hours')Running@cloudflare/worker-typesWorkflowEvent.instanceIdnpx wrangler workflowwrangler types --experimental-include-runtimeenv.WORKFLOW.get(id).status().outputevent.paramsevent.payloadSerialized RPC arguments or return values are limited to 1MiBstep_namestep_name{
"success": false,
"messages": [],
"errors": [
{
"code": 10001,
"message": "workflows.api.error.internal_server"
}
],
"result": null
}export function getApproximateSizeInBytes(obj: unknown) {
return new TextEncoder().encode(JSON.stringify(obj)).length;
}