Skip to main content

Troubleshooting Asset Create and Update

Summary​

This page covers rejected or failed asset create and update operations. An asset can be created through the compatibility path (a request via the asset-requests endpoint) or the native path. Required fields are validated in the aggregate and commands: tenant, asset code, name, type, status, and condition. The value objects for code, name, serial, and assignee validate on construction, so a malformed value is rejected before persistence. Updates run through the native or compatibility service. Most create and update failures are validation rejections rather than infrastructure faults.

Audience​

Support engineers and developers investigating why an asset could not be created or updated, or why a save was rejected.

Symptoms​

  • A create or update is rejected with a validation error.
  • A required field appears missing or malformed on the request.
  • A save does not persist and no asset appears in the tenant list.
  • A conflict is returned on create (see the duplicate-code page for that specific case).

Cause​

Scope​

This page covers field validation and value-object construction on create and update. Duplicate-code conflicts are covered on a dedicated page, and tenant-context 400s are covered on the tenant page.

Likely causes​

  • A required field (tenant, asset code, name, type, status, or condition) was missing or empty, so the aggregate or command rejected it.
  • A value object (code, name, serial, or assignee) received a malformed value and failed on construction.
  • The request used a shape that does not match the target path; native and compatibility payloads differ.
  • The tenant context was missing, which surfaces as a 400 before field validation matters.

Resolution​

Safe diagnostics​

  • Confirm all required fields are present and non-empty on the submitted request.
  • Confirm the values conform to the value-object rules for code, name, serial, and assignee.
  • Confirm which path was used (native versus compatibility) and that the payload shape matches it.
  • After a reported successful save, list assets for the tenant to confirm the record is present and reflects the submitted values.

Validation​

  • Confirm the corrected request is accepted and the asset appears in the tenant list.
  • Confirm the persisted values match the submitted values.
  • Confirm that an audit and timeline row exists for the change, which indicates the transaction committed.

Evidence to Collect​

  • The submitted field set and which fields were flagged.
  • The response status and error text returned on rejection.
  • Which path (native or compatibility) was used.
  • A correlation identifier and timestamp.

Escalation​

Route persistent validation behavior to the asset or backend team. Route compatibility payload-shape questions to the asset team as well, and route portal form issues to the frontend team.

Source References​

  • microservices/src/asset-service/Application/Commands/AssetCommands.cs
  • microservices/src/asset-service/Domain/Asset/Asset.cs
  • microservices/src/asset-service/Api/AssetCompatEndpoints.cs

See Also​

Keywords​

asset create, asset update, validation, value objects, required fields

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-17
  • Review cycle: Quarterly