traffic_ctl error handling

[masaori335]

I ran traffic_ctl config set command without enough privilege accidentally, however traffic_ctl was just quiet. Also, return code was 0. It'd be very helpful show error message or something if an error happens on running command.

[brbzull0]

This is what I am getting from an unauthorized user:

[test_traffic_ctl@fedora ~]$ /opt/ats/bin/traffic_ctl config set proxy.config.http.accept_no_activity_timeout 120 
Server Error found:
[10] Unauthorized action
- [2] Denied privileged API access for uid=1001 gid=1001
[test_traffic_ctl@fedora ~]$ echo $?
0

Error code is indeed 0 as traffic_ctl is interpreting this as output from ATS, this can for sure be changed.

@masaori335 could you please run the command using -f rpc at the end?

[masaori335]

$ traffic_ctl config get proxy.config.http.accept_no_activity_timeout
proxy.config.http.accept_no_activity_timeout: 30

$ traffic_ctl config set proxy.config.http.accept_no_activity_timeout 40 -f rpc
--> {"id": "d30bcb85-cd2f-4ef2-ab24-e2e3c42716c0", "jsonrpc": "2.0", "method": "admin_config_set_records", "params": [{"record_name": "proxy.config.http.accept_no_activity_timeout", "record_value": "40"}]}
<-- {"jsonrpc": "2.0", "result": "success", "id": "d30bcb85-cd2f-4ef2-ab24-e2e3c42716c0"}

$ traffic_ctl config get proxy.config.http.accept_no_activity_timeout
proxy.config.http.accept_no_activity_timeout: 30

I don't see the error message with -f rpc option. FWIW, ATS version is 10.0.6. Which version supports this?

[brbzull0]

Thanks for the details Masaori. This is/was indeed a Bug, and just found out this is fixed already. There was an issue filed for the same issue.

Wonder if we should cherry-pick this fix in some specific branch?.

[masaori335]

Oh, I approved the PR 😆 Seems like it goes 10.1.x, it should be ok. Then, the return code is the only issue we have.

[brbzull0]

Oh, I approved the PR 😆 Seems like it goes 10.1.x, it should be ok. Then, the return code is the only issue we have.

well the thing is, it's not the command itself who's failing as the command was succesfully executed, hence traffic_ctl is not setting the return code != 0.

Should we interpret successful executions by their error responses? maybe yes.