Currently in case of double activation, with optimistic concurrency, the first writer wins.
The original workflow SQL persistence provider used a "last reader" strategy: it "locked" the persisted row in database (instances in memory should refresh the lock in each 2 minutes to prove they are live), and the "etag" was incremented on each read. In case of double activation, only the last reader with the latest "etag" were able to write back the state.
This can be implemented with the blob provider, with a lease/break pair.

The state table supposed, that there always be an OnPaused event before OnSave, but it is wrong, there can be persistence at any time.
Solution: add OnPaused activities to OnSave also (register and unregister reminders).

Designers shouldn't use attributes, generate descriptions during design time on request.

Updating loaded workflows to a newer definition version. Though the separation of the application logic (the plain C# delegates) and the process (the diagram) results in a very simple workflow diagram, that has a big chance you won't need to update when it runs.

Currently the whole Dictionary<XName, InstanceValue> in IWorkflowState is serialized with NetDataContractSerializer and zipped with GZipStream. NetDataContractSerializer uses XML format (XmlDictionaryWriter). We should try to use Orleans or any other serializers.
NOTE: One of the special values in InstanceValue is the ActivityExecutor itself, and it's allegedly works only with NetDataContractSerializer.

Resize to small sizes is currently ugly.

There will be 4 of it (whether it has parameter and return value).
Usually you don't need a scope, because you don't need to do anything during the outgoing request.

Only after #29 #30 #31.

Even when in runnable state and there is already a reminder (based on a delay). That reminder can be far in the future. This way in case of failure the workflow will be reactivated sooner.

When activities execute grain delegates, sync context should be restored to original grain. Should? Isn't it restored yet?

I mean ReceiveRequestSendResponseScope and SendRequestReceiveResponseScope.
Currently every method name of the workflow interfaces are listed.

Not only the successful response, but the fact, that the operation was cancelled, should be persisted also.

The original WF persistence doesn't allow to load completed workflows, if we try to rehydrate an executor, the WorkflowInstance.InitializeCore will throw a NRE... But this is essential, if the client repeats a request due to a failure and we have idempotent responses, we should use them.

Workaround:

• we shouldn't store the executor in completed state
• we should always store the completion state, output arguments and termination exception
• let save and load the extensions
• add workarounds for every incoming method (operation and reminder resumption, Run and RunToCompletion, Deactivate, etc.)

Even if we can answer idempotent requests in completed state, we can't re-fire a normal outgoing WorkflowCallbackInterface operation or we shouldn't re-fire the OnCompleted event, because if those hadn't been successful the WF wouldn't have completed at all. So it's OK, if RunToCompletion's workaround can read the output arguments without the OnCompleted event, it's like an idempotent operation.

Or at least follow the selected items width.
http://stackoverflow.com/questions/1034505/how-can-i-make-a-wpf-combo-box-have-the-width-of-its-widest-element-in-xaml

fury.io chooses not the latest tag/release (lost among branches).
shields.io works for github, though nuget still broken.

These activities should work, but not tested yet:

• CancellationScope
• CompensableActivity and CompensationExtension

We should check to not make stack dives!!!
TaskCompletionSource-s for operations are created without TaskCreationOptions.RunContinuationsAsynchronously, and nearly all ContinueWith uses TaskContinuationOptions.ExecuteSynchronously.
When we go from sync OnNotifyUnhandledException and OnNotifyPaused to TAP async equivalents, there are two await Task.Yield(), these should break most of the loops.
NOTE: SendResponse's TaskCompletionSource.Task should continue ASAP, and not wait for the other activities in the WF, this way WF can run on the tail of the operations!
See eg.: http://stackoverflow.com/questions/28321457/taskcontinuationoptions-runcontinuationsasynchronously-and-stack-dives

Orleans currently doesn't have transaction support.
See also dotnet/orleans#1090 dotnet/orleans#1880

Currently the workflow is "preparated" ie. loaded (and started if it was saved in Runnable state) during OnActivateAsync(). It can cause exceptions that are propagated back to OnActivateAsync(), causing activation to fail. Will this cause reactivation in an infinite loop? Or waste silo resources?
The alternative is to delay the workflow preparation for the real incoming request or Reminder after activation, if it fails, the grain remains active and will reload and rerun the workflow on the next incoming request or Reminder, ie. will retry later without deactivation.

Can they be also value types, without boxing?

Currently semi manual, semi automatic MSTest.
Refactor it and use xUnit and Orleans scheduler.
Create/use something like MS.Activities.Test? (Ron Jacobs)
+Somewhere there is a Timeout in a parallel activity, it should be in a pick.
+Measure code coverage.

With:

• DI/Autofac
• Strategy and Humble Object patterns, to show an architecture, where the application logic can be tested independently from Orleans and from Orleans.Activities workflows

Remove CreateExtensions(), use factory as parameter in ctor.
Though there can be situations, where grain should add an extension for some custom activity, in this case it must use it's extension factory wrapper.

Add constraint to check whether the current operation name is in the list. Currently if the interface changes, the combobox is empty meantime the property contains the value, without any error message.

Currently it can be implemented through any TWorkflowCallbackInterface method, but a built in support would be easier, and it is better to see this kind of operations in the workflow designer and not hide inside operation delegates.
Or IdleDeactivationMode parameter like the IdlePersistenceMode parameter???

Do they work?

Reentrant grain, 2 ReceiveRequest activity in parallel, both parallel branch contains some Delay activity before SendResponse to emulate internal work.
Both request has to accepted and the workflow must idle in both Delay activity and send the responses in parallel.

To wait for the incoming request is cancellable, but the execution of the parameter delegate is not.
Also the outgoing requests return delegate is not cancellable.
The outgoing request is awaited by the scope without cancellation, this is a third place for an optional cancellable Task.

Currently only one taskCompletionSource can be protected with redirecting unhandled exceptions to it. WorkflowHost is reentrant, multiple parallel requests can be active.
This is a problem when eg. the workflow aborts, and we have to complete all taskCompletionSources.

VS extension or NuGet pkg?

Currently only arguments have description.

The difference is only 1 letter, it's confusing. "that's a semantics deathtrap" @Aaronontheweb :) I suggest:

• IWorkflowInstance - OK
• IWorkflowHost -> IWorkflowInstanceCallback because de facto this is a callback interface
• IAffector - IWorkflowHost
• IEffector - IWorkflowHostCallback
• TAffector - TWorkflowInterface
• TEffector - TWorkflowCallbackInterface

Test that when workflow runs on the tail of the already replied incoming request, Orleans scheduler really treat these delegates/tasks as belonging to the message.
Eg. non-reentrant grain will not accept another incoming request until the workflow goes idle.
Be aware, a delay in workflow makes it idle, it's tricky to test.

When the workflow cancels itself due to an unhandled exception in a ReceiveRequestSendResponseScope, the completion state of the workflow is Closed nod Canceled.

If we let the exception to buble up, and a real OnUnhandledException event occurs, that schedules workflow cancellation after the Idle event, the completion state will be correct.

I suppose, there is missing a context.MarkCanceled(); statement somewhere in this activity that prevents the default cancellation of the root activity to finally make Canceled it's state instead of Closed. The TaskAsyncNativeActivity turns off default Cancellation, if cancellation finally happens, MarkCanceled should be called somewhere.

See: http://blogs.msdn.com/b/carlos/archive/2013/02/06/wf4-workflow-foundation-4-understanding-cancellation.aspx

The © character is broken in the NuGet package.

To directly clear state when completed is dangerous, it removes idempotent informations also.
It would be better to register for a later (days, months) state clear, or enable some external archivation of the database with storing these info in eg. separate column.

This combines the calling of the RunAsync() method and then await-ing for an AsyncAutoResetEvent set by OnCompletedAsync(). This can be used only for short running workflows, long running computational workflows must use a callback from the OnCompletedAsync() "event".

Add sample to demonstrate usage.

There are 48 peaces of them.

Instead of plain logging.

And also separate samples into their own solutions based on NuGet.

Currently workflows are transaction scripts. Make them DSL.
In a template activity you can specify one or more activities as arguments (like the try/catch/finally arguments in TryCatchFinally activity).
And a body, where you can use these arguments.
This way you can build template activities based on this base like:

• "execute this activity in a loop in case of exceptions"
• "wait for this incoming request with a timeout and throw exception when it expires"

Because IMHO this is the simplest way to make them optionally dependent on runtime (practically incoming request's) values.
Eg. a public grain method can set an "immutable" property in grain state and factories executed later can use it.
The immutability can be ensured by code contracts.

Currently the workflow is not reloaded until the next incoming workflow related request or reactivation reminder (2 minutes), until this the non workflow related requests will read an obsolete state, that will be reloaded later.
Should we reload State after abort immediately (but not run, that can cause abort again), or let non workflow related requests to prepare the workflow state and implicitly the grain state?