Where is the transaction cache in VAF task queue?

You could call a vault extension method from the task processor.

Ok i'll give it a try

It is a bit unfortunate that in Hybrid transaction mode, the Job.Commit do not expose the underlying Environment because it uses the TransactionRunner that have it available in the callback. I just hope this will be adjust in a future release.

So my option is to go Unsafe and have my code use the TransactionRunner directly to get access to Environment but I lose the automatic handling of job status,

Or stay Hybrid and call an extension method like you suggest, which is a bit weird because the TransactionRunner does call an extension to have the transaction, which make and extension inside an extension, and the error handling is a bit worst.

I can see why you would like to have access to the full event handler environment information here.  What would you like to do differently for event handling though?

I just like to have the api updated to support

job.Commit((vault, environment) =>

I understand.  I would like to understand a little more about what impact this has on your error handling though.

If I understand correctly in Hybrid, any exception thrown will be grab automatically at higher call level and the job will be requeue. Calling commit will mark the job as completed.

I was about to create an internal exception class that will have a status and based on that status, I want different job result. Maybe I will just use the AppTaskException.

But my concern is what happens when I throw that exception inside the extension method.
Will it be processed correctly by the job method?

An exception will be thrown, but it may not be exactly the exception that's thrown inside the commit method; that exception has gone through serialization and back.

But I think you could probably pass the exception back through, something like this:

Exception e = null;
try
{
  job.Commit((transactionalVault) =>
  {
    e = new AppTaskException(...);
    throw e;
  });
}
catch
{
  // Now do something with "e", which is the actual exception you wanted.
}

I know that we did have some oddities in the original implementation of this whereby the commit call wouldn't run exactly where you expect, but I think the above should work now.

I'll have to do more testing on this. Right now I have the extension method in place and that part works perfectly.

That's what I mean by "the error handling is a bit worst." 

The exception received is a COMException and not what was thrown inside the extension method.
The InnerException is also null.

This is what the test look like.

// For reference
//ObjVerEx doc;

try
{
  job.Commit((transactionalVault) =>
  {
    // This extension method throw an exception
    transactionalVault.ExtensionMethodOperations.ExecuteVaultExtensionMethod("someextension", doc.ToString());
  });
}
catch (Exception e)
{
  // e is a COMException and the InnerException is null, not the real exception
}