Actual behavior of __context__ for execution modules?

[dbushong]

Per the docs "developing modules" section about __context__:

When running an execution module __context__ persists across all module executions until the modules are refreshed; such as when saltutil.sync_all or state.apply are executed.
...
Note: Because __context__ may or may not have been destroyed, always be sure to check for the existence of the key in __context__ and generate the key before using it.

And indeed, when I look at some of the builtin modules, e.g., they certainly seem to assume that it works that way (i.e. that __context__ is useful as a cache between runs)

However, when I actually try a simple example of (re-)using __context__, it seems to be reset on every call, e.g.:

root@d245ff4b26d3:/home/salt# salt mywin mystuff.counter
mywin:
    1
root@d245ff4b26d3:/home/salt# salt mywin mystuff.counter
mywin:
    1
root@d245ff4b26d3:/home/salt# salt mywin mystuff.counter
mywin:
    1

And counter.py is:

def counter():
    if "mycounter" in __context__:
        count = __context__["mycounter"]
    else:
        count = 0
    count += 1
    __context__["mycounter"] = count
    return count

Additionally, I turned on debug logging, and tried repeatedly running chocolatey.chocolatey_version that I linked above, and AFAICT from the logs, it is also never seeing any persistent values in __context__ and is always running from scratch.

Do I have some minion config settings wrong? (I tried with multiprocess: False and True with no difference)

Am I misunderstanding the documentation?

[max-arnold]

I think it might persist between multiple module calls that happen within a single run.

[dbushong]

I think it might persist between multiple module calls that happen within a single run.

I agree that that seems to be the behavior, but it (to my reading) pretty directly contradicts the docs. Unfortunately, my use case would rely heavily on the documented behavior.