forked from cerc-io/stack-orchestrator
Thomas E Lackey
5c275aa622
Related to cerc-io/webapp-deployment-status-api#10 There are two issues in that. One is that the output probably changed recently, whether in the client or server, where no matching record is found by ID (Note this is specific to `laconic record get --id <v>` and does not seem to apply to the similar command to retrieve a record by name, `laconic name resolve <n>`). Rather than returning `[]` it is now returning `[ null ]`. This cause us to think there *was* an application record found, and we attempt to treat the `null` entry like an Application object. That's fixed by filtering out null responses, which is a good precaution for the deployer, though I think it makes sense to ask whether this new behavior by the client/server is correct. Seems suspicious. The other issue is that all the defensive checks we had in place to deal with broken/bad AppDeploymentRequests were around the _build_. This error was coming much earlier, merely when parsing and examining the request to see if it needed to be handled at all. I have now added similar defensive error handling around that portion of the code. Reviewed-on: cerc-io/stack-orchestrator#922 Reviewed-by: zramsay <zramsay@noreply.git.vdb.to> Co-authored-by: Thomas E Lackey <telackey@bozemanpass.com> Co-committed-by: Thomas E Lackey <telackey@bozemanpass.com> |
||
|---|---|---|
| .. | ||
| build | ||
| data | ||
| deploy | ||
| repos | ||
| __init__.py | ||
| __main__.py | ||
| base.py | ||
| command_types.py | ||
| constants.py | ||
| main.py | ||
| opts.py | ||
| update.py | ||
| util.py | ||
| version.py | ||