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.

[dwoz]

I think it would be worth trying to track down if this feature worked at some point. Possibly before the loader refactor which took place in 3004.0? If so, this should be considered a bug. If not, then we should clarify the documentation.