Re-construct CommandInvocation between retries in shard-role SEP

XMLWordPrintableJSON

    • Type: Improvement
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Server Programmability
    • SP Prioritized List
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      On the router path, the CommandInvocation is recreated between each retry attempt, since the prior invocation's run() may have mutated the request state, which is permissible per the documentation (and is also done in practice).

      The shard's implemention of ServiceEntryPoint does not do this though, and instead it just calls run() on the old CommandInvocation instance again.

      The behavior here should be consistent regardless of role so that command implementations know whether they need to reset state for subsequent invocations.

              Assignee:
              Unassigned
              Reporter:
              Patrick Freed
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: