jakrams
commented
2 years ago Hey @robbbbbb thank you for the very detailed description. This gives us a lot of information to try to reproduce and get to the bottom of the problem, and we'll come back to you as soon as possible.
Generally this kind of conversion is pretty standard for GLTF files and we are currently not aware of any issues. The only thing that comes to my mind right now, is that the ARRT tool generates an access token for the entire container, so that the conversion service has full access to everything. Code is here. Maybe your token is more restrictive? Of course our ps1 scripts should do the right thing regardless, so we'll investigate that use-case.
To answer your last question: Yes, the conversion IDs are only kept in the database for a limited time (either a week or a month, can't remember the details). So it's expected that you don't get data about them anymore.
Sorry for the inceonvenience!
robbbbbb
Describe the problem
At some point in the last 2 months our method of converting certain models (which contain multiple files referenced by a single .gltf) has stopped working. We don't convert models like this that often, so we hadn't noticed the breakage and can't really narrow down exactly when it occurred.
Files that use a layout as simple as the following exhibit the problem:
<storagecontainer>/<dirname>/scene.gltf<storagecontainer>/<dirname>/scene.binAnd produce output .results.json files with contents like the following:
{"error":"2007","title":"The input asset is not valid.","details":{"import error":"GLTF: could not open referenced file \"scene.bin\""}}The code on our side which uploads the files to an input storage container and constructs + issues the REST request to start the conversion hasn't changed during the time since this was working.
We've also recreated the issue using the Conversion.ps1 powershell script in this repo and via manually constructing and issuing REST requests. Our accounts use and always have used linked storage, but just in case we've tried both with and without providing the
inputLocation.storageContainerReadListSasargument to the create request. We're seeing the same results in all cases.The one method that doesn't seem to generate this issue, and which does work, is the latest version of the ARRT tool. Performing the equivalent operations to kick off a conversion with the tool produces a successful result.
Provide additional information
Below I'll provide a bunch of conversionIds, how they got generated, and the error/success results for each. Unless otherwise specified, they used this file layout, which is just this sketchfab file, downloaded using sketchfab's 'autoconvert GLTF' download option:
. ├── license.txt ├── scene.bin └── scene.gltf
{"error":"2007","title":"The input asset is not valid.","details":{"import error":"GLTF: could not open referenced file \"scene.bin\""}},{"error":"2007","title":"The input asset is not valid.","details":{"import error":"GLTF: could not open referenced file \"scene.bin\""}}Additional context
In addition to those above, here are the conversion IDs for an old conversion of similar assets (i.e. a multi-file model obtained from sketchfab with identical file layout). These were both submitted for conversion to the same ARR resource, with the same storage account, using the same code and the same original assets (a gltf zip of this sketchfab asset).
One succeeded, one failed. Unfortunately these conversion IDs, despite coming from the API originally and being stored in our database, no longer seem to be available for lookup in the conversion API (or something else has gone wrong on our end and those conversions were somehow created in a different region/account, but I feel like that's unlikely looking at our code + config changelog). Do finished conversions have some kind of maximum lifetime after completion that they're available for query?