Caput with callback does not notify failure

No, this is not exactly a duplicate. In particular, this bug report is actually reporting a deficiency in the CA implementation of the return from Write Notify, whereas #1741844 is reporting a problem with the caput command line tool.

Clearly these two reports can be merged, as there is a common underlying issue, but the conversation in #1741844 completely misses the fact that the server side implementation of CA is failing to report completion failure.

To be clear. Your issue is ECA_NORMAL in the Write Notify case? This is write_notify_action() vs. write_action() in camessage.c. Can you say which Base version(s) are involved. write_notify_action() changed quite a lot from 3.14 -> 3.15.

If it's >=3.15 then I think I see a problem where the status is being dropped.

Alas, I'm only able to report against 3.14 at the moment.

Sorry, forgot to actually answer your question: yes, I'm reporting that Write Notify returns ECA_NORMAL even though the record processing step has rejected the put (by returning the appropriate error code from the record process function).

> If it's >=3.15 then I think I see a problem where the status is being dropped.'

Scratch that. There was an indirection which I didn't notice right away.

The return of dbProcess() is (and was) being ignored in dbNotify.c (used by CA put w/ callback, but is checked in dbPutField() which is used by CA put w/o callback.

3.14

https://github.com/epics-base/epics-base/blob/d3bcf5737fb9a627c82d3862aa14e565d4fbf88e/src/db/dbNotify.c#L233

7.0 (also >=3.15)

https://github.com/epics-base/epics-base/blob/5c6d275001c02c9ff818d0a7029eb7685360f072/modules/database/src/ioc/db/dbNotify.c#L264

@MD: We do have some tests for dbNotify in the base-3.16 and 7.0 trees; the tests for the input record types in src/std/rec/test/asynSoftChannel.* check the operation of the soft callback device supports which use dbNotify to do a processGet on the INP link target. Unfortunately though the target record used is a subRecord, which might seem ideal for testing this condition except that its process() routine always returns 0 no matter what the sub returns. Same for the aSub, and for various other record types as well.

The return value from process() has always been hard to work out how to use; if record A forward links to B and B's process() returns an error, should A's process() return that error code? If B is asynchronous and it only returns an error from the async-completion call to process() though, the error would go elsewhere... What to do with the status values from all the INP links that are PP so their process() routines are also called?

I have a small and simple change that might fix this, but I haven't worked out how to test it yet.

> The return value from process() has always been hard to work out how to use

Agreed, though dbProcess()!=0 seems a good place to start. Additionally,
maybe checking whether the targeted record has INVALID_ALARM after all processing
is complete? Alarms are the error propagation tool of choice in processing chains.