search

typesafehub / conductr-cli

CLI for Lightbend ConductR
Other
16 stars 21 forks source link

Following logs for app bundle that's scaled down throws error in CLI #522

Open seglo opened 7 years ago

seglo commented 7 years ago

CLI: 1.2.16

While testing the continuous-delivery feature I used conduct logs <partial app id> -f to see the effect of deploying a new app bundle to the running app bundle. Because the partial app id I used was ambiguous with the new app id (I used a new config bundle) I received an error.

Error: 300 Multiple Choices
Error: Specified Bundle ID/name: '9fbee2a' resulted in multiple Bundle IDs: '9fbee2a4f9ae430d828bacb6712ae004-b9df2af26d564e5e72d760481448496f, 9fbee2a4f9ae430d828bacb6712ae004-48968680570dd706fe77e2bbaf329696'
Error: Encountered unexpected error.
Error: Reason: TypeError object of type 'NoneType' has no len()
Error: Further information of the error can be found in the error log file: /Users/seglo/.conductr/errors.log
from the errors.log:
2017-07-18 09:23:33,707: Failure running the following command: ['conduct', 'logs', '9fbee2a', '-f']
Traceback (most recent call last):
  File "conductr_cli/main_handler.py", line 14, in run
  File "conductr_cli/conduct.py", line 35, in main_method
  File "conductr_cli/conduct_main.py", line 610, in run
  File "conductr_cli/validation.py", line 43, in handler
  File "conductr_cli/validation.py", line 59, in handler
  File "conductr_cli/conduct_logs.py", line 30, in logs
  File "conductr_cli/conduct_logs.py", line 96, in new_lines
TypeError: object of type 'NoneType' has no len()
tail: -n: No such file or directory
tail: 20: No such file or directory
1 Comment Collapse
longshorej commented 7 years ago

@typesafehub/prodsuite What's reasonable here? I'm thinking that once https://github.com/typesafehub/conductr/pull/1845 is merged, this feature should be simplified to simply connect to that endpoint and relay data. If the connection is dropped, the command exits, instead of attempting to ignore errors like it does currently. This makes us more like UNIX's tail -f instead of tail -F but perhaps that's more predictable anyways.