StartStreaming errors not passed to the caller

[farshidtz]

🐞 Bug Report

Affected Services [REQUIRED]

The issue is located in:

Is this a regression?

No

Description and Minimal Reproduction [REQUIRED]

Make sure that the rtsp is NOT running.

Start streaming:

$ curl -X PUT -d '{                                                                              
    "StartStreaming": {
      "InputImageSize": "640x480",
      "OutputVideoQuality": "5"
    }
}' http://localhost:59882/api/v2/device/name/Logitech_StreamCam-4B17BE45/StartStreaming
{"apiVersion":"v2","statusCode":200}

This returns 200 OK as if the requested operation was successful. If this HTTP request is just meant to accept the the operation and run it asynchornously, the response code should be 202 Accepted

Logs:

level=INFO ts=2022-05-19T11:48:31.864475627Z app=device-usb-camera source=driver.go:536 msg="start video streaming for device Logitech_StreamCam-4B17BE45"
level=ERROR ts=2022-05-19T11:48:32.774545384Z app=device-usb-camera source=driver.go:524 msg="the video streaming process for device Failed Finish FFMPEG ([-nostats -loglevel 0 -y -s 640x480 -i /dev/video0 -qscale 5 -f rtsp -hls_list_size 0 rtsp://localhost:8554/stream/Logitech_StreamCam-4B17BE45]) with exit status 1 message   has stopped, error: %!s(MISSING)"

🔥 Exception or Error

🌍 Your Environment

Deployment Environment:

EdgeX Version [REQUIRED]:

Anything else relevant?

[lenny-goodell]

@farshidtz , did #24 address this issue?
@cloudxxx8 , if issue still needs addressing, can your team take it?

[farshidtz]

@farshidtz , did #24 address this issue?

No, that is a fix for another issue.

[cloudxxx8]

@farshidtz this is the normal command API, and it is a Set Command provided by this Device Service
Set Command only supports 200 response for now.
This should be applied to the new device function in the future
edgexfoundry/edgex-docs#644

[lenny-goodell]

@iain-anderson , per @cloudxxx8 response, this is what it is due to Core Command capability.
Should we close as will not fix
or
should we discuss future refactoring of Core Command to allow for this?

[iain-anderson]

I think close. The functionality we are trying to provide doesn't really fit the model we are working with, so some inconsistency will manifest. Long-term the fix is to do it via device functions as per the above.

[lenny-goodell]

Closing per above discussion

[lenny-goodell]

Error needs to be captured prior to returning so the error can be returned.