bugfix: Workflow overhaul, new feature bugfix

[WhitWaldo]

Description

Fix for the workflow propagation integration tests not working as expected.

Issue reference

We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.

Please reference the issue this PR will close: #[issue number]

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 58.34%. Comparing base (62fe30d) to head (9fd34ca).

❗ There is a different number of reports uploaded between BASE (62fe30d) and HEAD (9fd34ca). Click for more details.

HEAD has 2 uploads less than BASE

Flag	BASE (62fe30d)	HEAD (9fd34ca)
net10.0	13	11

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1818      +/-   ##
==========================================
- Coverage   64.91%   58.34%   -6.57%     
==========================================
  Files         300      266      -34     
  Lines        8832     7838     -994     
  Branches     1040      913     -127     
==========================================
- Hits         5733     4573    -1160     
- Misses       2846     3083     +237     
+ Partials      253      182      -71     

Flag	Coverage Δ
net10.0	58.33% <ø> (-6.57%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[WhitWaldo]

@copilot Something about the workflow history propagation integration test are failing to run and timing out causing the tests to be cancelled after 30 minutes. These should take only a few seconds apiece to run each of the 5 tests:

Dapr.IntegrationTest.Workflow.HistoryPropagationWorkflowTests.ShouldCompleteSuccessfully_WithNoPropagationScope
Dapr.IntegrationTest.Workflow.HistoryPropagationWorkflowTests.ShouldCompleteSuccessfully_WithOwnHistoryPropagationScope
Dapr.IntegrationTest.Workflow.HistoryPropagationWorkflowTests.ShouldCompleteSuccessfully_WithLineagePropagationScope
Dapr.IntegrationTest.Workflow.HistoryPropagationWorkflowTests.GetPropagatedHistory_ReturnsNull_WhenScheduledWithNoneScope
Dapr.IntegrationTest.Workflow.HistoryPropagationWorkflowTests.WithHistoryPropagation_FluentBuilder_WorksCorrectly

Can you please take a stab at determining what about the implementation in Dapr.Workflow is not working correctly such that the tests are not passing? Don't read into the fact that the code was merged in a previous PR as proof-positive that the underlying code works. This appears to have been erroneously merged into mater. You can read more about the intended implementation details here

[Copilot]

@copilot Something about the workflow history propagation integration test are failing to run and timing out causing the tests to be cancelled after 30 minutes. These should take only a few seconds ap...

The tests were hanging due to two chained bugs in the PropagatedHistoryReceiver child workflow:

Bug 1 (fixed in edcc53e): The child workflow completed synchronously (Task.FromResult(result) with no await). When a Dapr sub-orchestration completes in the same turn it's first started, the sidecar never delivers the SubOrchestrationInstanceCompleted event to the parent — so the parent waits forever. The fix was await context.CreateTimer(TimeSpan.Zero) to force an async round-trip before returning.

Bug 2 (fixed in 44f9f19): CreateTimer(TimeSpan.Zero) produced a CreateTimerAction.fireAt equal to (or up to 99ns before) orchestrationStartTime. This precision loss happens because google.protobuf.Timestamp has nanosecond precision but DateTime only has 100ns (tick) precision — converting Timestamp→DateTime→Timestamp truncates sub-tick nanoseconds. Dapr 1.18.0-rc.3 validates fireAt >= orchestrationStartTime and silently rejects the timer when this is violated, so the child workflow is stuck waiting for a timer that never fires, and the parent never receives the completion event.

The fix in 44f9f19 adds fireAt = _currentUtcDateTime.AddTicks(1) when fireAt <= _currentUtcDateTime. This guarantees the emitted timestamp is always strictly after OrchestratorStarted.Timestamp, satisfying the runtime's validation.

I also added three unit tests in 0688edb to document and prevent regression of this behavior.

[Copilot]

@copilot Excellent. Let's proceed to re-implement the new 1.18 functionality. Please start by uncommenting out (or adding as necessary), the timer origin functionality was originally implemented at ht...

Re-enabled the timer-origin unit tests in test/Dapr.Workflow.Test/Worker/Internal/TimerOriginTests.cs (b5e45c2) — the file was fully commented out in 4ea4525. All 13 tests compile and pass on the post-proto-overhaul SDK without any source modifications. The implementation (WorkflowOrchestrationContext.CreateTimer overload, TimerOriginHelpers, and the TimerOrigin{CreateTimer,ExternalEvent,ActivityRetry,ChildWorkflowRetry} origin fields) and the integration tests (TimerOriginIntegrationTests.cs, 4 tests gated to Dapr ≥ 1.18) were never removed and are already active. Total Dapr.Workflow.Test: 355 passed, 0 failed on net9.0.