Conversation
* update packages * Split image upload and Image cropper mappers (to handle uploads in media slightly diffrently) * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * add missing xml comments * add debug , so we can see which mapper we hit. --------- Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
…ister anything for uSync. (only works on backoffice servers) (#962)
…der has no children (so last items get deleted) (#964)
Bumps [fast-uri](https://github.com/fastify/fast-uri) from 3.1.0 to 3.1.2. - [Release notes](https://github.com/fastify/fast-uri/releases) - [Commits](fastify/fast-uri@v3.1.0...v3.1.2) --- updated-dependencies: - dependency-name: fast-uri dependency-version: 3.1.2 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [postcss](https://github.com/postcss/postcss) from 8.5.8 to 8.5.14. - [Release notes](https://github.com/postcss/postcss/releases) - [Changelog](https://github.com/postcss/postcss/blob/main/CHANGELOG.md) - [Commits](postcss/postcss@8.5.8...8.5.14) --- updated-dependencies: - dependency-name: postcss dependency-version: 8.5.14 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
) Bumps [postcss](https://github.com/postcss/postcss) from 8.5.8 to 8.5.14. - [Release notes](https://github.com/postcss/postcss/releases) - [Changelog](https://github.com/postcss/postcss/blob/main/CHANGELOG.md) - [Commits](postcss/postcss@8.5.8...8.5.14) --- updated-dependencies: - dependency-name: postcss dependency-version: 8.5.14 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
#960) Bumps [uuid](https://github.com/uuidjs/uuid) to 14.0.0 and updates ancestor dependency [@umbraco-cms/backoffice](https://github.com/umbraco/Umbraco-CMS). These dependencies need to be updated together. Updates `uuid` from 13.0.0 to 14.0.0 - [Release notes](https://github.com/uuidjs/uuid/releases) - [Changelog](https://github.com/uuidjs/uuid/blob/main/CHANGELOG.md) - [Commits](uuidjs/uuid@v13.0.0...v14.0.0) Updates `@umbraco-cms/backoffice` from 17.3.0 to 17.5.0-rc - [Release notes](https://github.com/umbraco/Umbraco-CMS/releases) - [Commits](umbraco/Umbraco-CMS@release-17.3.0...release-17.5.0-rc) --- updated-dependencies: - dependency-name: "@umbraco-cms/backoffice" dependency-version: 18.0.0-rc1 dependency-type: direct:development - dependency-name: uuid dependency-version: 14.0.0 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite) from 8.0.5 to 8.0.16. - [Release notes](https://github.com/vitejs/vite/releases) - [Changelog](https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md) - [Commits](https://github.com/vitejs/vite/commits/v8.0.16/packages/vite) --- updated-dependencies: - dependency-name: vite dependency-version: 8.0.16 dependency-type: direct:development ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite) from 8.0.5 to 8.0.16. - [Release notes](https://github.com/vitejs/vite/releases) - [Changelog](https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md) - [Commits](https://github.com/vitejs/vite/commits/v8.0.16/packages/vite) --- updated-dependencies: - dependency-name: vite dependency-version: 8.0.16 dependency-type: direct:development ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…971) Bumps [markdown-it](https://github.com/markdown-it/markdown-it) from 14.1.1 to 14.2.0. - [Changelog](https://github.com/markdown-it/markdown-it/blob/master/CHANGELOG.md) - [Commits](markdown-it/markdown-it@14.1.1...14.2.0) --- updated-dependencies: - dependency-name: markdown-it dependency-version: 14.2.0 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…#974) Removes [js-yaml](https://github.com/nodeca/js-yaml). It's no longer used after updating ancestor dependency [@hey-api/openapi-ts](https://github.com/hey-api/openapi-ts). These dependencies need to be updated together. Removes `js-yaml` Updates `@hey-api/openapi-ts` from 0.95.0 to 0.97.0 - [Release notes](https://github.com/hey-api/openapi-ts/releases) - [Changelog](https://github.com/hey-api/hey-api/blob/main/CHANGELOG.md) - [Commits](https://github.com/hey-api/openapi-ts/compare/@hey-api/openapi-ts@0.95.0...@hey-api/openapi-ts@0.97.0) --- updated-dependencies: - dependency-name: "@hey-api/openapi-ts" dependency-version: 0.97.0 dependency-type: direct:development - dependency-name: js-yaml dependency-version: dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…rs (#985) Content template (blueprint) exports stored the parent DocumentBlueprintContainer as a raw, environment-specific int id in the friendly Path, and lost the parent key entirely, because the lookups assumed the parent was always the same object type as the item (DocumentBlueprint) rather than allowing for a container/folder. - ContentSerializerBase: fall back to an untyped entity lookup for both the friendly path and the exported Parent key/name when the typed lookup fails, and add virtual hooks (FindItemAsTreeEntityAsync, CreateParentIfMissingAsync) so parents can be resolved/created as ITreeEntity rather than TObject. - SyncTreeSerializerBase: CalculateNodePath/CalculateNodeLevel accept ITreeEntity? parents instead of TObject?, since TObject already implements it. - ContentTemplateSerializer: resolve the parent as either an existing blueprint or its DocumentBlueprintContainer folder, and create the missing folder chain on import (same find-or-create-on-the-way pattern used for content/data types) instead of dropping the blueprint at the root or failing. Fixes Jumoo/uSync.Complete.Issues#300.
…972) * Add localization fallback defaults and translate UI into 5 languages Replace all uSync-owned localization calls (`localize.term`) with `localize.termOrDefault`, supplying the English string as a fallback so the UI renders correctly even before the localization system has loaded. Umbraco core keys (e.g. `general_close`) are left as plain `term` calls since those are guaranteed to exist in every Umbraco installation. Add translations for Danish (da-dk), French (fr-fr), Spanish (es-es), German (de-de), and Dutch (nl-nl), covering all uSync and USyncSettings keys. Register all five new locales in the lang manifest. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * Add more localization changes. --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
* Use stack allocated spans instead of heap allocated arrays * avoid the last tiny heap allocation in the copyTo, TryWriteBytes will do this allocation free. --------- Co-authored-by: Kevin Jump <kevin@thejumps.co.uk>
Two sources of swallowed first-chance InvalidCastExceptions during push, ~100 each per run, that slow the app when a debugger is attached. 1. SyncEntityCache.GetName read from the entity cache (`cache`) while AddName wrote to `nameCache`. The entity cache holds IEntitySlim objects under the same id key, so every name lookup threw IEntitySlim -> CachedName and returned null - the name cache never actually worked. GetName now reads from nameCache. 2. Config/setting values arrive as JsonElement; Umbraco's TryConvertTo throws (and swallows) InvalidCastException turning a JsonElement into a value type e.g. bool. Added JsonTextExtensions.TryConvertPreChecked which does the JsonElement conversion with System.Text.Json first and only falls back to TryConvertTo. Routed the value/config wrappers (ConversionExtensions, SyncValueMapperBase, SyncSerializerOptions, HandlerSettingsExtensions) through it. Adds tests for both fixes. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
…eck) (#987) * Merge JsonElement pre-check into existing TryGetValueAs TryGetValueAs already did object -> T conversion with the same shape as the new TryConvertPreChecked, so fold the JsonElement pre-check into it (nicer name, one method) and use it everywhere. TryGetValueAs is now public and skips the pre-check for string targets: Umbraco's TryConvertTo already turns a JsonElement into a string without throwing, and routing an object/array JsonElement through Deserialize<string> would throw - reintroducing the exact first-chance exception this change avoids. Its two existing string callers keep their current behaviour. Renames the test file to match. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Route remaining TryConvertTo calls through TryGetValueAs Consolidates the object -> T conversions onto the single TryGetValueAs method so they all get the JsonElement pre-check, and adds a non-generic Type overload for the two callers that only have a runtime Type (ContentTypeSerializer history-cleanup, ContentSerializerBase value diff). Converted: XElementExtensions (value/attribute ValueOrDefault, CreateOrSetElement), ObjectPropertyExtensions, ListExtensions, JsonTextExtensions.GetPropertyValueOrDefault, MediaPicker3Mapper, MemberGroupPickerManager, DomainSerializer, ContentTypeSerializer, ContentTypeBaseSerializer. Left ContentTypeBaseSerializer.SerializeNewProperty on TryConvertTo: it writes an empty XElement when conversion succeeds with a null result, a success-vs-null distinction TryGetValueAs deliberately collapses (null -> false). Converting it would drop empty elements and cause spurious diffs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Route SerializeNewProperty through TryGetValueAs too Converts the last object -> T conversion so TryConvertTo is only used in one place (inside TryGetValueAs itself). TryGetValueAs treats a null conversion result as failure, so the else branch keeps writing an empty XElement - the property is still recorded in the xml, matching the old success-with-null behaviour. The old hard-fail-writes-nothing case is unreachable in practice here (reflected value-type properties return boxed defaults, not null; string already took the empty path). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Two hot-path optimisations in XElementExtensions: 1. ValueOrDefault<TObject> (XElement + XAttribute overloads) now fast-paths the value types actually used (int, Guid, bool, enum) with direct parsers before falling back to Umbraco's reflection-based TryConvertTo. These getters run for (almost) every attribute of every node during a report/import, so avoiding the reflection/exception overhead adds up. The typeof(TObject) checks are JIT-folded per generic instantiation. 2. MakePlatformSafeHashAsync streams the XML straight through a CryptoStream instead of buffering the entire serialised document into a MemoryStream before hashing. The hashed byte sequence is unchanged, so hashes stay stable across platforms. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The 'clean' import path needs only the Key attribute for every item in a folder, but was fully parsing each .config file (XElement.LoadAsync with PreserveWhitespace) to read it. On large content/media trees this is a second full file-IO + parse pass over the folder during every import that contains clean markers. Add ISyncFileService.LoadKeyFromFileAsync which streams the file with an XmlReader, reads the Key attribute off the root element and stops - no DOM allocation, no reading the rest of the document. Wire it into the clean path: - SyncHandlerRoot.GetFolderKeysAsync (the per-folder key scan) - SyncHandlerRoot.GetCleanParentAsync - SyncHandlerBase.GetCleanParentKeyAsync, which also now reuses the key for the parent lookup instead of loading the clean file twice. Behaviour is unchanged: the root Key attribute is present on both normal and 'empty' (delete/rename/clean) nodes, files without a Key still yield Guid.Empty, and read errors still throw so a corrupt file aborts the clean rather than silently allowing deletes. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
…+guid (#990) Two ExportOnSave / bulk-operation performance fixes from the perf review. #5 - runtime-cache scope (was keyed by managed thread id): GetCacheKeyBase() built its key from Environment.CurrentManagedThreadId. Across an await a continuation can resume on a different thread, so the key changed mid-operation - the child-item / folder-key caches missed (extra entityService calls) and the end-of-operation cleanup (on another thread) never cleared the entries it created, leaking them into the shared runtime cache. Replace the thread id with an AsyncLocal<string> scope id that flows with the async operation. PrepCaches/CleanCaches (import + report) and the top-level ExportAllAsync now begin/end a scope via BeginCacheScope/ EndCacheScope, and ImportAllAsync/ReportAsync run the cleanup in a finally so entries are always released. Callers with no active scope (paged import, ad-hoc tree/dependency lookups) fall back to the thread id, so their behaviour is unchanged. #3 - skip CleanUp folder scan on flat + guid names: On every save/move/delete, SyncHandlerRoot.CleanUpAsync recursively reads the whole handler folder tree looking for duplicate files to mark as renames. With a flat structure and guid file names an item's file is always "{key}.{ext}" in the same folder - it never changes name or location - so there is nothing to clean. Add an early return for that case to the base handler (Content/Media already made this check in their override, this extends it to the settings/level/container handlers). Build clean; uSync.Tests 137/137 pass. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Findings doc (no code changes). Decompiled Umbraco 17.3 ContentService to compare Save(item) vs Save(IEnumerable), and traced uSync's import scope handling. Conclusion: bulk Save is not a safe general win for content/media - - the batch overload still writes one row per item (no set-based SQL), so the dominant cost is unchanged; - its only saving (N->1 transactions + N->1 notifications) either is already provided by uSync's ambient suppressed scope (DisableNotificationSuppression = false), or, in the default config, directly conflicts with the per-item failure isolation that default is intentionally designed to give; - it also drops per-item error attribution and two validations. Recommends leaving the (already-present but dormant) bulk hook off for content/media and using the existing config levers instead. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Findings doc (no code changes). Decompiled Umbraco 17.3 ContentService to compare Save(item) vs Save(IEnumerable), and traced uSync's import scope handling. Conclusion: bulk Save is not a safe general win for content/media - - the batch overload still writes one row per item (no set-based SQL), so the dominant cost is unchanged; - its only saving (N->1 transactions + N->1 notifications) either is already provided by uSync's ambient suppressed scope (DisableNotificationSuppression = false), or, in the default config, directly conflicts with the per-item failure isolation that default is intentionally designed to give; - it also drops per-item error attribution and two validations. Recommends leaving the (already-present but dormant) bulk hook off for content/media and using the existing config levers instead. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* Fix: move property out of group on import (#1009) Importing a content type where a property has been moved out of all groups (empty <Tab> and no matching <Tabs> entry) did nothing - the property stayed in its original group. DeserializePropertiesAsync only handled properties moving *into* a tab. When the tab alias resolved to empty for an existing property, the else branch fell through without action. Now, when an existing property has no tab in the config but is still in a group, it is queued to move to "no group" via MovePropertyType(alias, null), which Umbraco treats as removing it from its current group. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Fix: re-home property into no-group so move persists in one import (#1009) Moving a property out of all groups still needed two imports. Root cause: Umbraco's MovePropertyType(alias, null) removes the property from its group but does NOT add it to the 'no group' collection - it orphans the property, so the first import's save doesn't persist the move. MoveProperties now re-adds the property with AddPropertyType after the move to null, which lands it in NoGroupPropertyTypes. Added unit tests documenting the orphaning behaviour and verifying the workaround. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
…ets (#999) Bumps [brace-expansion](https://github.com/juliangruber/brace-expansion) from 2.0.3 to 2.1.2. - [Release notes](https://github.com/juliangruber/brace-expansion/releases) - [Commits](juliangruber/brace-expansion@v2.0.3...v2.1.2) --- updated-dependencies: - dependency-name: brace-expansion dependency-version: 2.1.2 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…1007) Bumps [linkify-it](https://github.com/markdown-it/linkify-it) from 5.0.1 to 5.0.2. - [Changelog](https://github.com/markdown-it/linkify-it/blob/master/CHANGELOG.md) - [Commits](markdown-it/linkify-it@5.0.1...5.0.2) --- updated-dependencies: - dependency-name: linkify-it dependency-version: 5.0.2 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
) Bumps [fast-uri](https://github.com/fastify/fast-uri) from 3.1.2 to 3.1.4. - [Release notes](https://github.com/fastify/fast-uri/releases) - [Commits](fastify/fast-uri@v3.1.2...v3.1.4) --- updated-dependencies: - dependency-name: fast-uri dependency-version: 3.1.4 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Removes [js-yaml](https://github.com/nodeca/js-yaml). It's no longer used after updating ancestor dependency [@hey-api/openapi-ts](https://github.com/hey-api/hey-api/tree/HEAD/packages/openapi-ts). These dependencies need to be updated together. Removes `js-yaml` Updates `@hey-api/openapi-ts` from 0.95.0 to 0.97.0 - [Release notes](https://github.com/hey-api/hey-api/releases) - [Changelog](https://github.com/hey-api/hey-api/blob/main/packages/openapi-ts/CHANGELOG.md) - [Commits](https://github.com/hey-api/hey-api/commits/@hey-api/openapi-ts@0.97.0/packages/openapi-ts) --- updated-dependencies: - dependency-name: js-yaml dependency-version: dependency-type: indirect - dependency-name: "@hey-api/openapi-ts" dependency-version: 0.97.0 dependency-type: direct:development ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [ws](https://github.com/websockets/ws) from 7.5.10 to 7.5.13. - [Release notes](https://github.com/websockets/ws/releases) - [Commits](websockets/ws@7.5.10...7.5.13) --- updated-dependencies: - dependency-name: ws dependency-version: 7.5.13 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [@hey-api/openapi-ts](https://github.com/hey-api/hey-api/tree/HEAD/packages/openapi-ts) from 0.97.0 to 0.97.3. - [Release notes](https://github.com/hey-api/hey-api/releases) - [Changelog](https://github.com/hey-api/hey-api/blob/main/packages/openapi-ts/CHANGELOG.md) - [Commits](https://github.com/hey-api/hey-api/commits/@hey-api/openapi-ts@0.97.3/packages/openapi-ts) --- updated-dependencies: - dependency-name: "@hey-api/openapi-ts" dependency-version: 0.97.3 dependency-type: direct:development ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
--- updated-dependencies: - dependency-name: ws dependency-version: 7.5.11 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
) Bumps [fast-uri](https://github.com/fastify/fast-uri) from 3.1.4 to 3.1.5. - [Release notes](https://github.com/fastify/fast-uri/releases) - [Commits](fastify/fast-uri@v3.1.4...v3.1.5) --- updated-dependencies: - dependency-name: fast-uri dependency-version: 3.1.5 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…1023) Bumps [postcss](https://github.com/postcss/postcss) from 8.5.15 to 8.5.26. - [Release notes](https://github.com/postcss/postcss/releases) - [Changelog](https://github.com/postcss/postcss/blob/main/CHANGELOG.md) - [Commits](postcss/postcss@8.5.15...8.5.26) --- updated-dependencies: - dependency-name: postcss dependency-version: 8.5.26 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
#1037) * Fix: save blueprints via SaveBlueprint on the bulk save path ContentTemplateSerializer overrides SaveItemAsync to save through IContentService.SaveBlueprint, but inherited SaveAsync(IEnumerable<IContent>) from ContentSerializer, which saves through IContentService.Save. That persists the blueprint via DocumentRepository, rewriting umbracoNode.nodeObjectType from DocumentBlueprint to Document, so the next import can no longer find it and fails with a duplicate key error. Backport of #1035 to v17. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Use Task.CompletedTask instead of FromResultOf wrapper for clarity Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
…ok serializers (#1039) SaveItemAsync discarded the Attempt<T, Status> returned by ILanguageService, IDictionaryItemService, and IWebhookService, so a failed create/update (e.g. an ISO code rejected by Umbraco's IsoCodeValidator) was silently dropped while the import still reported success. Now throws when the attempt fails, so the failure surfaces in the import results and log instead of vanishing. Fixes #1038 Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
ContentTypeBaseSerializer (Media/Content/MemberType), ContentTypeSerializer, DataTypeSerializer, DomainSerializer, TemplateSerializer, MediaSerializer, and ContentSerializer all discarded (or logged-only) the Attempt/OperationResult from their underlying Create/Update/Save/Delete calls, the same silent-failure pattern fixed in #1038/#1039 for Language/DictionaryItem/Webhook. Each now checks success and throws with the operation status/result on failure, so the failure surfaces in the import results and log instead of being reported as a successful import. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Template import failures (#1044) reported a generic "Failed to create template" with a null exception, hiding the actual Umbraco status (e.g. duplicate alias) - especially hard to diagnose on IIS/Production where the failure mode differs from local dev. Propagate attempt.Status and wrap it in an exception so the sync result carries enough detail to diagnose. Also removes an unreachable duplicate null check left over from an earlier refactor, and adds coverage for both the failure and success create paths. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
exception: null, giving no way to diagnose why creation failed - notably on IIS/Production, where the failure only reproduces in that environment and not locally.TemplateSerializer.DeserializeCoreAsyncnow surfaces Umbraco's realTemplateOperationStatus(e.g.DuplicateAlias) in the message and wraps it in anInvalidOperationException, matching the same "don't discard save-attempt results" fix already applied to other serializers in Fix silently discarded save failures in Language/DictionaryItem/Webhook serializers #1039/Fix discarded save-attempt results across remaining serializers #1041 (this call site was missed).item is nullcheck left over from an earlier refactor.Test plan
uSync.Tests/Serializers/TemplateSerializerTests.cscovering the template-create failure path (asserts the real status/exception now flow through) and the success path.dotnet test uSync.Tests/uSync.Tests.csproj- 141/141 passing.