intersystems / intersystems/pyprod
iris.ref() values not cleaned up on exception
- Dominant language
- Python
- Stars
- 10
- Forks
- 7
- PR merge metrics
- No merged PRs in 30d
Description
- iris kit details: 'any'
- operating system: 'any'
- python version: 'any'
- error message: 'N/A — no crash, but resources held longer than necessary'
#### Steps to Reproduce:
1. Have a BusinessService/BusinessProcess/BusinessOperation call SendRequestSync
2. Have the IRIS-side call throw an exception (timeout, connection drop, invalid request)
3. The iris.ref() cleanup lines are unreachable
#### Minimal Example
```
# In _production_connector.py, the pattern is:
response = iris.ref()
status = self.iris_host_object.SendRequestSync(...) # can throw
response_value = response.value # unreachable on exception
response.value = None # unreachable
del response # unreachable
```
#### Expected Behaviour
iris.ref() objects are cleaned up regardless of whether the call succeeds or fails.
#### Actual Behaviour
On exception, cleanup is skipped. Python's GC will eventually collect the ref object
when the traceback is released, but until then the IRIS-side object it references stays
pinned. In a long-running production with intermittent failures, this means IRIS resources
are held longer than necessary (duration depends on how long the exception/traceback lives
in the error handling chain).
This is a robustness/hygiene issue rather than a critical bug — the process doesn't crash
and GC will eventually reclaim the resources. But in long-running workers it's better to
release immediately via try/finally.
#### Additional Information
Affected methods:
- `BusinessService.SendRequestSync`
- `BusinessProcess.SendRequestSync`
- `BusinessOperation.SendRequestSync`
- `InboundAdapter.BusinessHost_ProcessInput`
- `AdapterNamesToPascal` method wrapper
Suggested fix: wrap in try/finally to ensure `response.value = None` runs unconditionally.
Contributor guide
Research direction
Start in _production_connector.py and inspect the listed SendRequestSync methods, InboundAdapter.BusinessHost_ProcessInput, and the AdapterNamesToPascal wrapper. Trace each iris.ref() call and its exception path, then verify that response.value is cleared whether the IRIS-side call succeeds or raises.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 75/100