HttpContext is NULL after "SendReply" gets executed RRS feed

  • Question

  • I have a workflow which executes the following activities. I don’t want the client to wait for the complete execution so I have “SendReply” before executing the custom activities. Custom Activities are long running activities.  The client calls the WF service asynchronously. After executing “SendReply” the response goes back to the client as expected but when the next CustomActivity gets executed, I get HttpContext is NULL in the custom activity.

    If I let the workflow executes continuously and send the response back to client at the end of the workflow then HttpContext remains NOT null.

    The activities executes in the following order




    “Delay”: why delay see the link below

    CustomActivity1: In this activity is HttpContext is NULL




    Why there is a delay after sendreply: http://msmvps.com/blogs/theproblemsolver/archive/2010/11/17/throttling-workflow-services-in-wf4.aspx

    Monday, January 23, 2012 5:06 AM


  • Why is HttpContext.Current null?

    Well, actually nobody has ever documented that Receive and SendReply provide HttpContext.Current to the rest of the workflow (real or implied). You observed it sometimes does, sometimes doesn't. But it's not part of the contract of these activities to do something meaningful to HttpContext.

    This observed behavior seems weird, what can explain it?

    Imagine your workflow has something like thread static state - that is what HttpContext.Current comes from.
    Basically that all of your workflow 'thread' state gets destroyed and recreated if your workflow goes idle, and delay activity makes your workflow go idle.

    So is the solution to rely on observed behavior and not to use delay?
    Better question, as a best practice 'should I try to use HttpContext.Current' in my workflow where I get it from Receive/SendReply activities?

    No, there is just no guarantee this will work. If you do this you are relying on some undocumented behavior or other. Or that it stops working when you change some other part of your workflow, even further away.

    So, what can you do instead? My recommendation for now is to check out IReceiveMessageCallback as explained by Maurice in case it lets you do what you want to do. ISendMessageCallback is a similar deal.



    • Edited by Tim Lovell-Smith Wednesday, January 25, 2012 6:52 AM
    • Proposed as answer by Tim Lovell-Smith Wednesday, January 25, 2012 6:52 AM
    • Marked as answer by lax4u Wednesday, January 25, 2012 3:58 PM
    Wednesday, January 25, 2012 6:45 AM