Windows Connector Updates: Test Beyond Version Checks

DEV Community

Test your Windows connector after the installer exits

A version check during an update can be accurate and still tell you too little. On our Windows test workstation, the new connector reported its version and served demo reads while the update command was still running. The failure appeared when that command's execution environment ended. We build both products involved. Local Commander lets an assistant work on a selected machine. Nulio connects to a 1C database using the employee's 1C access. On November 14, 2026, we used Local Commander to launch a Nulio update from 1.1.24 to 1.1.25. About a minute later, the connector console showed 1.1.25 and demo reads succeeded. The update command had not returned. At the 15-minute timeout, the runner terminated its process tree. The connector was then down, and its startup entry still pointed to 1.1.24. After correcting that entry and independently launching 1.1.25, we could see all 16 configured databases and successfully query one demo database. That established a narrower result than “the update passed”: the new binary could run and perform that read when launched separately. The lifetime boundary we missed Follow-up investigation found that the new connector remained in the runner's Windows job. That job terminated its processes when closed. Windows job objects allow processes to be managed as a group, including terminating processes belonging to the job. The successful reads happened before that boundary. They demonstrated operation while the update session was alive. A stand-in host later survived for 90 seconds after a modified launcher returned. That was evidence about the stand-in, not acceptance evidence for the released connector. A later real 1.1.26 update returned after 19 seconds with a nonzero exit, and no healthy read was verified afterward. The cause of that later failure remained unknown. We also had not confirmed why the startup entry stayed on the old version. Four checks for your next update test Use an authorized test workstation with representative configuration and a known, permitted read through the connector. Record the baseline. Capture the running version, the configured autostart target and the result of your known read. Choose a read whose expected result you can recognize and repeat. Observe the new version before the installer returns. While the update is running, check which version is actually serving requests and repeat the read. Record that the installer is still active. This is an intermediate observation. Check again after the installer ends, from a separate session. Record the installer's exit status. Then independently inspect the running connector's version and repeat the same read. Use this session to observe the real result; manually starting or repairing the connector first would obscure whether the update left it working. Repeat after a fresh workstation start. Verify the running version and perform the same read again. This tests whether startup configuration brings back the intended version without intervention. Keep the results for each boundary separately. “New version served a read during installation,” “still served it after installer exit” and “returned after a fresh start” are three distinct observations your release record should preserve. AI agents drafted this article from our team's incident notes and test records.

Powered by Readybot.io