chaining of exceptions using samp_hub
- Dominant language
- Python
- Stars
- 5.3k
- Forks
- 2.2k
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 75
Description
### Description
SAMP clients issuing blocking commands (ecall_and_wait with timeout=0) do not get notified of peer exception.
### Expected behavior
ecall_and_wait should raise an exception back to the client when the peer dies
### How to Reproduce
It is a little bit convoluted do to the distributed nature of the issue.
1) start a samp_hub with a well know SAMP_HUB file
```
samp_hub -f $HOME/.samp_demo
```
2) start our peer (here, ds9), using the hub
```
export SAMP_HUB=std-lockurl:file://$HOME/.samp_demo
ds9 -samp hub no -samp client yes -title myds9
```
3) start our astropy samp client
```
export SAMP_HUB=std-lockurl:file://$HOME/.samp_demo
```
and start python
```python
from astropy.samp import SAMPIntegratedClient
s = SAMPIntegratedClient()
s.connect()
s.get_subscribed_clients('ds9.set')
# gives {'cli#1': {}}
# sanity check (ok)
s.ecall_and_wait('cli#1', 'ds9.get', '0', cmd='version')
# gives {'samp.result': {'value': 'myds9 8.7b1'}, 'samp.status': 'samp.ok'}
# issue a blocking command
s.ecall_and_wait('cli#1', 'ds9.get', '0', cmd='iexam key coordinate')
# (this waits for the user to press a key on ds9 for coordinates)
```
- kill the ds9 instance (window)
- our python client is still stuck in ecall_and_wait
----
this only happens when using samp_hub.
If one connects SAMPIntegratedClient directly to the built-in ds9 samp hub (`ds9 -samp hub yes`, on ds9 window kill, the exceptions are correctly propagated back to the client.
### Versions
```python
import astropy
astropy.system_info()
astropy.version.version
```
```
AttributeError: module 'astropy' has no attribute 'system_info'
'5.3.3'
```
Contributor guide
Research direction
Start by reproducing the blocking ecall_and_wait case with an external samp_hub, SAMPIntegratedClient, and a peer running ds9, then compare it with ds9's built-in SAMP hub behavior. Trace ecall_and_wait through the SAMP hub path and verify that killing the peer causes the client to receive an exception rather than remain blocked.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- distributed-systems, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100