Skip to main content

Troubleshooting Asset Assignment

Summary​

This page covers assignment problems. An asset must be in an assignable state before it can be issued. The assignee is captured as an identifier reference only; it is not validated against employee-service, because the asset service holds no employee client or foreign key. Approving in the UI sets the status to Issued and emits AssetAssigned. Parallel or duplicate assignment is not prevented by a database one-active-assignment constraint. Assignment history rows are written in the same transaction as the assignment.

Audience​

Support engineers and developers investigating why an asset could not be assigned, why an assignee reference looks unvalidated, or why an asset appears assigned more than once.

Symptoms​

  • An assignment is rejected because the asset is not in an assignable state.
  • The assignee reference does not resolve to a known employee.
  • An asset appears assigned in parallel or to more than one holder.
  • The status did not move to Issued after approval, or no AssetAssigned event appears.

Cause​

Scope​

This page covers the assignment transition, the assignee reference model, and parallel-assignment behavior. Approval routing is covered on the requests-and-approval page.

Likely causes​

  • The asset was not in an assignable state, so the aggregate rejected the transition.
  • The assignee identifier is a reference only and is not checked against employee-service, so an unresolved reference is expected behavior, not a defect.
  • No database constraint prevents parallel assignment, so two assignment paths can both proceed.
  • The approval path did not complete, so the status stayed below Issued and no AssetAssigned event was emitted.

Resolution​

Safe diagnostics​

  • Confirm the asset's current status is an assignable state before expecting an assignment to succeed.
  • Treat the assignee as an identifier reference; do not expect the asset service to validate it against employee data.
  • If parallel assignment is suspected, read the assignment history rows, which are written in the same transaction, to observe what occurred.
  • Confirm whether approval reached Issued and whether AssetAssigned was recorded to the outbox, using read-only surfaces.

Validation​

  • Confirm the status is Issued after a successful assignment.
  • Confirm an assignment history row exists for the change.
  • Confirm an AssetAssigned row is present in the outbox diagnostics for the assignment.

Evidence to Collect​

  • The asset's status before and after the attempt.
  • The assignee identifier used.
  • Whether parallel assignment attempts occurred and their timing.
  • A correlation identifier and timestamp.

Escalation​

Route assignment-state logic to the asset or backend team. Route assignee-identity expectations to the asset team, noting the intentional absence of an employee-service check, and to identity or employee owners for cross-service validation questions.

Source References​

  • microservices/src/asset-service/Domain/Asset/Asset.cs
  • microservices/src/asset-service/Application/Commands/AssetCommands.cs
  • microservices/src/asset-service/Domain/Common/Enums.cs

See Also​

Keywords​

assignment, issued, assignee reference, parallel assignment, assignment history

Revision Information​

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