-
Notifications
You must be signed in to change notification settings - Fork 10
Description
Problem
waitForExternalEvent() in runtime-orchestration-context.ts (line 367) uses toLocaleLowerCase() to normalize event names, while handleEventRaised() in orchestration-executor.ts (line 421) uses toLowerCase().
These two methods produce different results in certain locales. For example, in the Turkish locale:
"ITEM".toLowerCase()→"item""ITEM".toLocaleLowerCase()→"ıtem"(dotless ı)
When a user calls ctx.waitForExternalEvent("ITEM"), the pending task is stored under the key "ıtem" (Turkish). When the executor later receives an EventRaised event named "ITEM", it looks up the key "item" (standard). The keys do not match, so the event is buffered instead of completing the task, causing the orchestration to hang indefinitely.
Root Cause
Inconsistent use of string lowercasing methods between two tightly coupled code paths:
runtime-orchestration-context.ts:367—name.toLocaleLowerCase()orchestration-executor.ts:421—event.getEventraised()?.getName()?.toLowerCase()
This also violates the SDK's core determinism invariant: toLocaleLowerCase() depends on the system locale, meaning the same orchestration code running on machines with different locale settings could produce different event name keys, breaking replay.
Proposed Fix
Change toLocaleLowerCase() to toLowerCase() on line 367 of runtime-orchestration-context.ts to match the executor's behavior. Add unit tests verifying case-insensitive event matching works correctly across the waitForExternalEvent() → handleEventRaised() boundary.
Impact
- Severity: High — can cause orchestrations to hang indefinitely in non-English locales
- Affected scenarios: Any orchestration using
waitForExternalEvent()with mixed-case event names, running on a system with a non-default locale (Turkish, Lithuanian, etc.) - Determinism violation: Locale-dependent behavior in orchestration context code