Hello, thanks for the continued feedback on our new api!
I am a little confused what is being asked for here though. Curl doesn’t usually propagate non-200 http errors as a non-zero exit-status, which seems what you are trying to accomplish. I wouldve expected this to fail for old API as well?
function RegisterDevice() {
echo "== Registering device (deviceID: ${DEVICE_ID}) in system, and downloading credentials."
cd "$(mktemp -d)" || exit 1
http_code=$(curl -s -w '%{http_code}' --max-time 30 -X POST -H "Authorization: Bearer $PROVISIONING_TOKEN" "$AUTOPROV_URL" -d "{\"device_id\": \"${DEVICE_ID}\", \"device_name\": \"${DEVICE_NAME}\"}" -o device.zip)
if [[ ! $http_code -eq 200 ]]; then
# if we failed, device.zip will be a text file with the errors
echo -e "${RED}"
echo "Failed to download token :("
echo "HTTP ERROR ${http_code}"
cat device.zip
echo -e "${NC}"
exit 1
fi
}
Now, that being said, it’s possible i completely misunderstood your question… Our API endpoints should be responding with the proper HTTP errors (like 404 for that non-existent-endpoint, etc), if they aren’t it would be considered a bug.
Thanks for the follow-up. Sounds like I’ll have to look into this more; I was basing my comments of our prior script(s) which (it sounds like incorrectly) made that behavioural assumption. My mistake if it’s a PEBKAC error.
Unfortunately I need to resurrect the original issue in a different form, as we are now encountering lockboxes that again refuse to install - this time though due to the root metadata being expired. Inspection of the JSON shows the expiry of the root files isn’t being bumped out when the lockbox is created; we ended up with a lockbox built on July 10th (with an expiry of 1 year) that no longer works because the root metadata expired on August 25th of this year. Even in lockboxes built after that date, the root metadata is only ever extended by a year and not to the expiry date of the lockbox itself.
We’re currently looking into this. Just to ask some clarifying questions about your situation.
First of all, when you’re talking about Lockbox creation/built could you specific what exact actions that means?
For example is “creation” defining the Lockbox on the web UI and “building” is when you download the files with TorizonCore Builder? Or do you mean something else?
Another question the team had is. Are you seeing this with completely new Lockboxes that you are defining in the web UI, or are you seeing this with old Lockboxes that you are updating, or are you seeing it with both?
Apologies for the confusion. In our case I am using those (define/build) interchangeably, in our CI setup, we both define the lockbox (via API v2 call) and then build it in the same process.
We see this both on rebuilt lockboxes (where we bump the new expiry via the API and then rebuild it) as well as newly created ones, e.g. a new customer-facing software version which did not have a lockbox before.
Thank you for the clarification. This was already brought to the attention of our cloud team. They’ll investigate and see if something strange is going on with regards to the expiry not being appropriately bumped for the metadata.
I’ll give an update once something is available to share.