Add signal connection cache

[stan-dot]

No description provided.

[stan-dot]

re: testing the signal. how should I instantiate the object? with epics_signal_rw or the constructor?

@coretl

[stan-dot]

@coretl I narrowed down where the knowledge gap is https://github.com/bluesky/ophyd-async/actions/runs/9397709655/job/25881480270?pr=368

[coretl]

You can also remove the parameterization from

ophyd-async/tests/core/test_mock_signal_backend.py

Lines 24 to 37 in 0b05b9c

	@pytest.mark.parametrize("connect_mock_mode", [True, False])
	async def test_mock_signal_backend(connect_mock_mode):
	mock_signal = SignalRW(MockSignalBackend(datatype=str))
	# If mock is false it will be handled like a normal signal, otherwise it will
	# initalize a new backend from the one in the line above
	await mock_signal.connect(mock=connect_mock_mode)
	assert isinstance(mock_signal._backend, MockSignalBackend)
	assert await mock_signal._backend.get_value() == ""
	await mock_signal._backend.put("test")
	assert await mock_signal._backend.get_value() == "test"
	assert mock_signal._backend.put_mock.call_args_list == [
	call("test", wait=True, timeout=None),
	]

and set mock=True always to make that test work

[stan-dot]

the error string does not appear to be present anywhere but in the test. not sure where is it coming from .

[stan-dot]

async def test_signal_can_be_given_backend_on_connect():
    sim_signal = SignalR()
    backend = MockSignalBackend(int)
    assert sim_signal._backend is None
    await sim_signal.connect(mock=False, backend=backend)
    assert await sim_signal.get_value() == 0

what is the goal of this test? right now it clashes with the caching implementation. we can either stop supporting this use case and drop the test (easy) or somehow change it OR the implementation of the feature (hard)

that test was added 6 months ago by Rose

[coretl]

that test was added 6 months ago by Rose

Looks like it was added quite recently to support supplying backend on connect:

We have to keep the test.

I suggest we always force a reconnect if backend is supplied, as this will only be used if the Signal is part of a Device, in which case the caching will happen there.

@evalott100 do you agree?

[stan-dot]

support supplying backend on connect:

I think I am missing some context. what does this do, when it is used and why do we support it?

[coretl]

support supplying backend on connect:

I think I am missing some context. what does this do, when it is used and why do we support it?

This is used when we know that a Signal will exist, like in

ophyd-async/src/ophyd_async/panda/_common_blocks.py

Lines 31 to 37 in cbbb295

	class SeqBlock(Device):
	table: SignalRW[SeqTable]
	active: SignalRW[bool]
	repeats: SignalRW[int]
	prescale: SignalRW[float]
	prescale_units: SignalRW[TimeUnits]
	enable: SignalRW[str]

but we don't know what PV it will connect to until connect(). What we will do is create the given SignalRW with backend=None, then on Device.connect() we actually create the backend and pass it to Signal.connect().

[stan-dot]

huh, I'd never have guessed that

[stan-dot]

should we have a flag for a case like that? it looks quite unusual. I'm thinking a flag next to 'force_reconnect' and 'mock'. then we can do logic flow around that.

[coretl]

should we have a flag for a case like that? it looks quite unusual. I'm thinking a flag next to 'force_reconnect' and 'mock'. then we can do logic flow around that.

The flag is a supplied backend. If backend is not None we should force a reconnect, otherwise do the existing behaviour

[stan-dot]

this is the error I get, but it looks like expected:

File "/workspaces/ophyd-async/tests/core/test_signal.py", line 80, in test_signal_connect_fails_if_different_backend_but_same_by_value
    assert str(exc.value) == "Backend at connection different from initialised one."
AssertionError: assert 'Cannot make a MockSignalBackend for a MockSignalBackends' == 'Backend at connection different from initialised one.'
  
  - Backend at connection different from initialised one.
  + Cannot make a MockSignalBackend for a MockSignalBackends

[stan-dot]

these two are too similar, I'd delete the second one or change the expected message. because the value is different.

[stan-dot]

[evalott100]

what is the goal of this test? right now it clashes with the caching implementation. we can either stop supporting this use case and drop the test (easy) or somehow change it OR the implementation of the feature (hard)

It tests that you can choose to pass the signal backend in at runtime - why would this be hard to support with your changes?

[evalott100]

these two are too similar, I'd delete the second one or change the expected message. because the value is different.

I don't mind putting them in the same test but it's still nicer to check that equality by value and by ref

[stan-dot]

@evalott100 now the latest version has both tests, just the expected string is different for the second test

[evalott100]

@evalott100 now the latest version has both tests, just the expected string is different for the second test

That makes sense, you got rid of the validation on the backends in the new connect logic

[stan-dot]

ok, trying to make this right now

[evalott100]

Suggested change

	await mock_signal_rw.connect(mock=False)
	RE(ensure_connected(mock_signal_rw, mock=True))
	assert (
	mock_signal_rw._connect_task
	and mock_signal_rw._connect_task.done()
	and not mock_signal_rw._connect_task.exception()
	)
	await signal_rw.connect()
	RE(ensure_connected(signal_rw))
	assert (
	mock_signal_rw._connect_task
	and mock_signal_rw._connect_task.done()
	and not mock_signal_rw._connect_task.exception()
	)

This test would have misleadingly failed I assume... The second connect wouldn't have succeeded since mock changed value, however it wouldn't have updated the connect_task so the assert here would have shown the first connect task was successful and passed.

I'm assuming you're choosing a soft signal over a mock signal because you want to mimick the performance of real signals within the connect? I'd like to see a version of this test where you use a real pva signal, passing mock=True on both connects.

Edit

Because of the unset _previous_connect_was_mock we don't get failure from changing mocks.

[stan-dot]

I'm assuming you're choosing a soft signal over a mock signal because you want to mimick the performance of real signals within the connect? I'd like to see a version of this test where you use a real pva signal, passing mock=True on both connects.

so mock=True creates a 'real pva signal'? I lost the plot

[evalott100]

I made a commit causing Device to fail on connect if mock changes value. Realised it was probably nicer to fail outright for Devices too.

A couple more changes left.

[evalott100]

Please respond to this

https://github.com/bluesky/ophyd-async/pull/368/files#r1650538856

This test would have misleadingly failed I assume... The second connect wouldn't have succeeded since mock changed value, however it wouldn't have updated the connect_task so
the assert here would have shown the first connect task was successful and passed.

[stan-dot]

that test is the only one that uses ensure_connected, but seems to pass even if I change is as much as here:

[evalott100]

#368 (comment)

Same as above comment. This will always work because it's a soft_signal - but we want it to fail on the first connect.

[stan-dot]

ok, I see now - so here we test a scenario where the device rejects at first but later accepts.

I think the best way to do this is to have a mock device that has its own connect with this 'fail on first connect' functionality, to mimic a real life device that misbehaves when we try to connect to it. So a similar class to this one:

[evalott100]

Do it by swapping out a MockSignalBackend's connect. That way you'll still be using the regular connect method/functionality of Device and Signal.

[evalott100]

Nice job! I don't know if we want to wait for @coretl to give this a once over before merging, but I'm happy with it.

[coretl]

One minor comment, otherwise good to go