The point being that the stack is not affected by the "pass", which means that when the other endpoint returns, it will return back to the caller - not to the one that "passed".
This would be of use in "dispatcher" scenarios, where you might have a "case" style evaluation of the incoming message, and then either handle it yourself, or send the control over to some other endpoint (possibly one of several other endpoints) - so that when they again return, it will be to the original caller.
A specific situation where this could be of use, is if you have a job that for some specific Ids takes a lot of memory (e.g. customers with over 1000 orders), you could do a "pass" to another instance of effectively the same endpoint, but which had concurrency set to 1 (or a few), instead of the 32 that your standard endpoint has. Thus, you would avoid the situation where if a massive influx of these customers that use a lot of memory, you would not go out of memory while processing them all at once.
Maybe consider both being able to pass, and target a specific "label" on the receiving endpoint.
Must at least be possible to send initial state with a pass, so that you could target "yourself" (the code), but on a different endpoint Id. That is, e.g. one method was annotated with two @MatsMappings, one with the public EndpointId, and one with a "private" EndpointId whose concurrency was 1. Thus, in the scenario above with the memory exhaustion, you could first check if the incoming state had the boolean "passedDueToLargeCustomer" set true, and if so, go directly to processing (you are in the "private" endpoint, and this flow now has concurrency=1). If it was not passed with this boolean true, you are in the "public" endpoint, and then you'd first check if the customerId in question was a "large customer", and if so, pass it to your private instance with incoming state passedDueToLargeCustomer=true, and if not, then go to processing.
An alternative to using incoming state to denote that you are being passed, you could use a TraceProperty (i.e. "ThreadLocal"-semantics).
Do note that context.goto(label), with label=FIRST, would be the same. Issue centiservice/mats#69. Should maybe just drop this "pass" idea and instead make that a special application of goto.
The point being that the stack is not affected by the "pass", which means that when the other endpoint returns, it will return back to the caller - not to the one that "passed".
This would be of use in "dispatcher" scenarios, where you might have a "case" style evaluation of the incoming message, and then either handle it yourself, or send the control over to some other endpoint (possibly one of several other endpoints) - so that when they again return, it will be to the original caller.
A specific situation where this could be of use, is if you have a job that for some specific Ids takes a lot of memory (e.g. customers with over 1000 orders), you could do a "pass" to another instance of effectively the same endpoint, but which had concurrency set to 1 (or a few), instead of the 32 that your standard endpoint has. Thus, you would avoid the situation where if a massive influx of these customers that use a lot of memory, you would not go out of memory while processing them all at once.
Maybe consider both being able to pass, and target a specific "label" on the receiving endpoint. Must at least be possible to send initial state with a pass, so that you could target "yourself" (the code), but on a different endpoint Id. That is, e.g. one method was annotated with two @MatsMappings, one with the public EndpointId, and one with a "private" EndpointId whose concurrency was 1. Thus, in the scenario above with the memory exhaustion, you could first check if the incoming state had the boolean "passedDueToLargeCustomer" set true, and if so, go directly to processing (you are in the "private" endpoint, and this flow now has concurrency=1). If it was not passed with this boolean true, you are in the "public" endpoint, and then you'd first check if the customerId in question was a "large customer", and if so, pass it to your private instance with incoming state passedDueToLargeCustomer=true, and if not, then go to processing.
An alternative to using incoming state to denote that you are being passed, you could use a TraceProperty (i.e. "ThreadLocal"-semantics).
Do note that context.goto(label), with label=FIRST, would be the same. Issue centiservice/mats#69. Should maybe just drop this "pass" idea and instead make that a special application of goto.