How an import actually runs

This is the path a finding takes between a scanner and a screen, and the places it can stop. Most "the import did not work" tickets are the import working correctly at a stage the reporter cannot see.

Nothing happens synchronously

Submitting an import does not process it. It writes a queue entry and returns. A worker picks the entry up afterwards and does the work.

That is why the upload succeeds instantly and the data appears minutes later, and why "the upload worked but nothing changed" is the normal appearance of a queued job, not evidence of a failure.

upload  →  staged  →  queued  →  worker consumes  →  matched  →  filed  →  visible

The five stages, and what failure looks like at each

Stage	What happens	If it stops here
Upload	The file is accepted and stored	An immediate error on screen — the only stage that reports failure to the person who triggered it
Staging	Rows are parsed into staging	Rows are set aside as failed with a per-row reason; the job still reports as processed
Queue	A message is published to RabbitMQ	Status stays PENDING indefinitely — the queue took it, nothing is consuming
Worker	A consumer processes the message	Status goes to FAILED, or sticks at IN PROGRESS if the worker died mid-message
Merge	Rows are matched and written to live tables	Data is present but attached to the wrong asset, or duplicated

Queue status is one of PENDING, IN PROGRESS, COMPLETED, FAILED. The tool-sync queues additionally use a partially completed state, which means exactly what it says: some hosts or assets in the batch succeeded and others did not, and the job will not be retried automatically.

COMPLETED does not mean every row was imported

A job completes when the worker finishes processing the message. Rows rejected during staging had already been set aside as failed before the worker ran. A completed import with fewer findings than the source file is the expected outcome of a partly invalid file — not a contradiction.

Check the failed-row count before concluding the import lost data.

Where to look, in order

1. Process Manager — is the job PENDING, IN PROGRESS, FAILED or COMPLETED? This answers "is it stuck or is it working" in one look, and it is the first thing to check on any import ticket.
2. The import queue log — per-job history, including how long it took. A job that normally takes two minutes and has been running for forty has not hung by design.
3. Failed rows — the per-row rejection reasons. Almost always a column mapping problem or a date format the parser did not accept.
4. The module screen — with the audit filter cleared. Findings do arrive but land against a different audit than expected more often than they go missing.

Nothing is moving at all

If every job across every module is PENDING, the problem is not the import. Either the message broker is not reachable or no workers are running, and the same symptom will show on scheduled reports and outbound email, because they use the same queues.

Confirm by checking whether a report queued now also stays pending. If it does, this is an infrastructure question, not a data one.

Matching: why a re-import does not double everything

Each finding is matched against what NxSAM already holds before it is written. A finding seen before updates the existing record and keeps its history, its SLA clock and its ownership; only genuinely new findings are created.

Two consequences worth knowing:

• Re-importing the same file is safe. It will not duplicate findings. It will, however, update last seen dates, which shifts what "recently detected" shows.
• If matching changes, history splits. Change the fields that identify a vulnerability and the next import will not recognise existing findings as the same ones. They will be created fresh — the old ones stay open with no new sightings, the new ones arrive with no history. This is the single most disruptive configuration change available in the product, and it is not reversible by changing the setting back.

Timing and the "missing" findings

The asset must exist before the finding can attach to it. An import that references an asset NxSAM does not have will either create it or reject the row, depending on the module. Where assets come from a synchronised source, an import that runs before the asset sync completes can reject rows that would have succeeded twenty minutes later.

If an import failed once and succeeded on retry with no change made in between, this is almost always the reason.