You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should the vcd version rather come from configuration? You get a 406 on a later version of vcd with the below error message when the version is set to 5.1.
Also is adding @system wise to do here? What if a user sets the config to xxxx@system in the configuration? A warning should perhaps be added to the configuration schema in config.schema.yaml
Also perhaps we should catch anything that isn't a 200 status code here and give a nicer looking error message?
Hard coded domain: Yes, it does look like the domain of @SYSTEM is hard coded here: https://github.com/StackStorm-Exchange/stackstorm-vcd/blob/master/actions/lib/vcd.py#L55 . Similar to the version number, i'm thinking this should probably be part of the config with a default value of SYSTEM and the code can insert the @ itself. Alternatively we could expect the user to be fully qualified and append @system if there is no @ character in the user.
@nmaludy Since the module supports the use of different vcd instances, it would make sense for the api version to be set per instance - so alongside hostname, username and password.
I feel like the solution of appending the @system if no @ is present in the string is a good one.
These changes could break existing workflows and actions, they would need to update their config. Is that acceptable?
Should the
vcd
version rather come from configuration? You get a406
on a later version ofvcd
with the below error message when theversion
is set to5.1
.message="The request has invalid accept header: . Supported API versions are: [32.0, 31.0, 30.0, 29.0, 28.0 [D], 27.0 [D], 26.0 [D], 25.0 [D], 24.0 [D], 23.0 [D], 22.0 [D], 21.0 [D], 20.0 [D]] ([D] indicates deprecated versions)"
Also is adding
@system
wise to do here? What if a user sets the config toxxxx@system
in the configuration? A warning should perhaps be added to the configuration schema inconfig.schema.yaml
Also perhaps we should catch anything that isn't a
200
status code here and give a nicer looking error message?The text was updated successfully, but these errors were encountered: