Auto-detect AutoComplete setting #244
Conversation
|
a rough test with Benchmark.net indicates a ~30ms computation overhead and ~7KB extra allocations caused by the stackwalk logic per invocation. |
|
What if we put a version with a boolean parameter behind an
Or:
If we cannot find the attribute, the exception message can point the user to the advanced method. Our generated code can jump straight to using the advanced method. People who do not want the overhead caused by the trigger-finding code can fall back to using the advanced method. Users who are hand-generating the function are unlikely to call the advanced method. I spiked what this would look like in #247 |
| /// <summary> | ||
| /// Processes a message received from an AzureServiceBus trigger using the NServiceBus message pipeline. | ||
| /// </summary> | ||
| public Task ProcessNonTransactional(Message message, ExecutionContext executionContext, IMessageReceiver messageReceiver, ILogger functionsLogger = null) => Process(message, executionContext, functionsLogger); |
There was a problem hiding this comment.
Should we be calling in to an obsolete method? We're going to have to fix it as soon as we update to 2.0 anyway.
There was a problem hiding this comment.
it was just to not duplicate the code because the obsoleted message still needs to work and it can't call ProcessNonTransactional because of the missing receiver (or pass null but I didn't like that). I'm fine either way.
src/NServiceBus.AzureFunctions.InProcess.ServiceBus/ReflectionHelper.cs
Outdated
Show resolved
Hide resolved
mikeminutillo
left a comment
mikeminutillo
left a comment
There was a problem hiding this comment.
Happy for this to go to the transactions branch
# Conflicts: # src/NServiceBus.AzureFunctions.InProcess.ServiceBus/FunctionEndpoint.cs # src/ServiceBus.Tests/FunctionEndpointTests.cs
* first draft of transaction support * add missing logging integration * tweaks * Add support for cross-entity transactions configuration via attribute * Approve API * switch invoked method based on transaction setting * please code style * make the generated code valid syntax * update approval files * verify generated trigger compiles without errors * remove optional ctor parameter for public attribute properties * update tests * cleanup tests * obsolete NServiceBusEndpointNameAttribute * suppress CS0618 * use single process implementation * delete comment * Native message may not have a messageId * Extract transaction strategy * use single process implementation * delete comment * Native message may not have a messageId * add some unit tests around the Process implementation * Extract transaction strategy * Fix tests * Refactor * Auto-detect AutoComplete setting (#244) * locate attribute to read AutoComplete value * rename public APIs * remove obsolete method usage * extract reflection code into helper * add more details to the reflection helper exception message * merge AttributeDiscoverer and ReflectionHelper methods * Update src/NServiceBus.AzureFunctions.InProcess.ServiceBus/NServiceBusTriggerFunctionAttribute.cs Co-authored-by: Mike Minutillo <mike.minutillo@particular.net> * use explicit interface impl. to hide Process on FunctionEndpoint * inline SafeCompleteAsync * update attribute property name * use existing function name * approve API changes * prevent potential NRE Co-authored-by: Sean Feldman <feldman.sean@gmail.com> Co-authored-by: Sean Feldman <SeanFeldman@users.noreply.github.com> Co-authored-by: Mike Minutillo <mike.minutillo@particular.net>
Adding a new Process method to the
IFunctionEndpointinterface while obsoleting the old process method. The new method which is intended to be called by users that do not use the auto-generated trigger will detect theAutoCompletesetting by walking up the CallStack.This comes at an additional computation & allocation cost but prevents users from using the wrong tx/non-tx method with incompatible AutoComplete settings.
The
FunctionEndpointclass itself exposes the explicit operations to do transactional/non-transactional processing for advanced uses cases. This is also the API used by the generated triggers.