Desktop version
Platform: 8.5.1.1423 (1Ci international), Windows Server 2022, MSSQL 2019.
After upgrading the same environment (identical configuration and deploy chain) from 8.5.1.1343 to 8.5.1.1423, the failure rate of the FIRST `ibcmd config import` attempt into a re-registered infobase increased from 0/5 runs (1343) to 2/3 runs (1423), with the same retry (repeat import+apply pair) always succeeding. This suggests the non-deterministic first-attempt behaviour is platform-version dependent and has worsened in 8.5.1.1423.
Root-cause analysis: we reproduced the failure outside CI with a fresh database restore before every attempt, importing the same XML dump with the same ibcmd 8.5.1.1423: 5 failures out of 8 runs (pā0.6), with the reported "unknown predefined object" varying between runs (4 different objects across runs of the identical dump), while every reported object IS defined in the dump (Predefined.xml present and valid). Timings point to the mechanism: on 8.5.1.1343 a clean import of this configuration takes ~52-56 s; on 8.5.1.1423 it takes ~10 s, i.e. XML reading appears to be parallelized in 1423 ā and the reference-to-predefined validation seems to race with reading the Predefined.xml of the referenced object, producing a false "Link to unknown predefined object" error. Failed attempts took 4.0-15.3 s, clean ones 9.9-11.4 s (fully overlapping ā failure is not timing-distinguishable). A repeated import into the same (partially processed) database succeeds noticeably more often than the first one. `ibcmd infobase config import` exposes no --jobs/--threads option to force sequential reading, so no user-side workaround exists apart from retries.
Full evidence set (stderr captures, timings table, dump inventory) available on request.