[KevinJump]

Why

A customer reported that usync-import wasn't bringing in new Umbraco Forms, while importing just the Forms group from the backoffice did. In an "all" run the Forms handlers always go last, and the CLI sends one request per handler. Anything that stops the run part way skips Forms, and the old CLI gave little sign that this had happened.

I couldn't reproduce it on a clean site (Umbraco 17.8.1, uSync 17.6.2, uSync.Forms 17.2.0). Testing turned up several ways a long run can fail quietly before it reaches Forms.

What changed

• Progress: each handler is printed as it completes ([17/18] Forms : 4) instead of dots.
• Failures: a failed step names the handler and the cause (timeout, HTTP status, or exception), says the later steps didn't run, and exits with code 1. A run where any item fails also exits non-zero, so pipelines notice.
• Token refresh: Umbraco's client-credentials tokens expire after 300 seconds, and the CLI used one token for the whole run. It now gets a new one every 2 minutes. GetAccessToken no longer resets HttpClient.BaseAddress, which throws once the client has sent a request.
• Timeout: each request gets 30 minutes instead of the HttpClient default of 100 seconds. It can be changed with uSync:Command:Timeout (a TimeSpan) in appsettings.json.
• Start step: the first request is sent with an empty RequestId, so the server runs StartProcessAsync (starting notifications and cache clear). Before, the CLI sent a fresh GUID, so the start step never ran.
• Default set: without --set, the set is left empty and the server uses its configured default. The old default, "default", didn't match the case-sensitive named options registered as "Default".
• Background mode: if the server runs uSync in Background processing mode, the CLI says so instead of reporting 0 changes. Following background runs would need the API client regenerated, so that's left for later.
• The readme has a short section on the new behaviour and the timeout setting.

Testing

Tested against a local v17.8.1 site with uSync and uSync.Forms:

• full and forced imports, a Forms-only import (--set Default --group Forms), and an export all complete with per-handler output and exit code 0
• the timeout set to 0.3s fails on step 3 with a clear message and exit code 1
• with the token refresh interval temporarily set to zero (a new token on every step), runs complete without errors
• the site log now shows "[uSync] - Starting Import process" for CLI runs

Package updates

The second commit moves the CLI's Microsoft.Extensions/AspNetCore packages from 10.0.11 to 10.0.15, which clears the SignalR advisory GHSA-334f-vvp4-7g6p (fixed in 10.0.13) that showed up as a warning whenever the CLI was built. The in-repo test site moves to Umbraco 17.8.1 and uSync 17.6.2. uSync.Command.Setup keeps its pinned Umbraco 17.6.2, so it still warns about Umbraco's transitive MessagePack and System.Security.Cryptography packages.

Not in this PR

While testing I hit a server-side hang. After the CLI timed out on the Datatypes step, the server kept running that step. A second import started a few seconds later never finished: the Datatypes step, which holds uSync's import lock, was waiting on an SQLite write lock. That needs looking at in uSync itself.

🤖 Generated with Claude Code