fix: restore module globals in execute_in_revit_context before ExternalEvent fires

[Wurschdhaud]

When the IronPython engine clears a non-persistent script scope, or when the cached engine for a command is the startup-script engine (same TypeId via SessionUUID:EngineType:Extension), module references like forms, revit, and any other split-backend module can disappear from func.__globals__ before the ExternalEvent callback executes, causing NameError.

Snapshot all module-type globals at scheduling time and restore any that are missing just before the function is called. Only module objects (type(v) is type(compat)) are restored, so mutable Revit state (doc, uidoc, etc.) is never overwritten with stale values.

Unsure, but seems to be a less of a bandaid fix than #3327. Maybe another AI has an opinion on that?

---

Checklist

Before submitting your pull request, ensure the following requirements are met:

• Code follows the PEP 8 style guide.
• Code has been formatted with Black using the command:

  pipenv run black {source_file_or_directory}

• Changes are tested and verified to work as expected.

---

Related Issues

If applicable, link the issues resolved by this pull request:

• Resolves [Bug]: On the first run of "Measure 3D" an error is thrown #3285

[devloai]

PR Summary:

• Fixes NameError: name 'forms' is not defined (#3285) in execute_in_revit_context when a non-persistent IronPython engine clears its script scope before an ExternalEvent fires.
• Snapshots all module-type globals from func.__globals__ at scheduling time and restores any that are missing just before the function is called.
• Wraps the user function in a _func_with_modules closure assigned to the singleton _HANDLER.

Review Summary:

The fix correctly identifies that asynchronous ExternalEvent dispatch can fire after the IronPython engine has cleared the script scope, wiping module references like forms. However, the implementation has a few concerns worth considering:

1. Silent call-drop with the singleton handler — _HANDLER is module-level singleton; rapid back-to-back calls overwrite .func/.args/.kwargs, silently discarding all but the last scheduled invocation. This pre-existing design limitation becomes more impactful here because each call now creates a unique closure with its own _saved_modules snapshot that gets thrown away. A deque-based queue would fix this properly.

2. func.__globals__ mutation leaks into the module namespace — In IronPython 2, func.__globals__ is the module's __dict__. Lines 218–220 mutate it directly, making the restored names visible to all code running in that module, not just this call. A local shadow dict (copy of globals + restored entries) passed to a new function object would isolate the side effects.

3. Scheduling-time snapshot can itself be stale — If forms is cleared by an engine reset and then freshly re-imported between scheduling and execution, the snapshotted old reference gets restored over the fresh import, which is the opposite of the intended effect. The simpler fix in PR #3327 (adding the missing import to the correct module) directly removes the root cause without these runtime patching concerns.

Suggestions

• Replace the singleton _HANDLER with a collections.deque-based queue so rapid successive execute_in_revit_context calls don't silently drop earlier scheduled invocations. Apply
• Scope the globals restoration with a try/finally that removes injected keys afterward to prevent polluting the shared module __dict__ for other callers. Apply

[sanzoghenzo]

I haven't used IronPython for far too much to know if my comments are applicable or not 😅
looks good overall