A new product appearing in a work screen can look like successful retrieval. Rereading the actual code showed a path that retains supplied material as a review candidate after a failed source read. Rather than discarding that useful continuation, I wanted source retrieval and candidate construction to retain separate states.
Read several outcomes inside a request to make it work
The historical request asked for the program to work. A review report described correcting imports that had treated failed URL retrieval as success; the next question asked how information would be obtained from other sources. I read the actual import function and candidate construction together instead of expanding that report into a claim that live external integrations were complete.
The documents also describe different moments. An older handoff discusses preparation before API integration, while the README identifies a local demo with mocked external connections. I ran no original server or external account in this review. Historical test and screen reports remain historical evidence; this run directly examined selected code conditions and a newly authored independent synthetic example.
A failure without supplied material stops before candidate creation
The add function validates a URL and waits for the import response. If the request fails and no initial title or candidate metadata is available, it returns an error without adding a product. Even supplied metadata cannot continue when the error text matches the code's blocking classification. I read that branch as an attempt to stop a failed read from being hidden by creation of an empty product.
A substring test on an error message is not a complete failure classifier. A reliable distinction between unavailable retrieval and a blocking decision needs an explicit connector contract. The shared example accepts unavailable and blocked classifications but performs no network validation or blocking itself. This content task did not modify the original application's classification logic.
A candidate supplied through CSV does not prove a source read
The CSV path passes a title, prices and options as initial material. If remote retrieval is unavailable, an allowed fallback can still create a candidate, with a separate warning returned by the add function. The CSV loop, however, increments its success count when result.ok is true. That counts created candidates; it cannot be described as the number of products successfully read from their source pages.
The direct URL path appends a returned warning to its notice, while the CSV summary does not consume that warning. Continuing review of supplied material can be useful, yet the explanation for that continuation can disappear in the display layer. A maker must decide how candidate creation and source verification will be counted separately. This article records the code distinction, not the result of a real CSV import executed here.
A merged object can hide which fields were actually read
Before the independent example, the app spreads initial material first and API metadata afterward. An API response containing an empty title can therefore overwrite an initial title. An explicitly supplied isMock value is also retained, so that flag cannot account for the origins of individual fields. These are conditions visible in selected static code, not an incident reproduced with real user material.
The server extracts a title, description, images, address and extraction time. It is not a function that reads every price and inventory field. Meanwhile the demo generator supplies template prices, options and an image-count display default. Reading a title does not establish those other values as source observations. This connects to the existing field-evidence article, but the new question concerns fallback merging and candidate counts.
Rebuild the fallback as a separate synthetic contract
The new module takes a fetch classification and separate fetched and provided observations, returning individual field origins. Blank titles cannot erase supplied material, zero remains a valid numeric value, and malformed types are not silently converted. Five records show a block with no candidate, supplied material after an unavailable read, insufficient empty results and mixed-origin fields.
I first reviewed the existing numeric evidence and batch-import modules. Neither owned this combination of fetch classification and fallback field selection, so I implemented a narrow independent example. Twenty-six tests ran in its source folder and again after extraction. These are not a rerun of the historical app's twenty-six tests. The new contract was not installed in that app and authenticates no source content.
Explore the implementation
An actual synthetic candidate result
{
"fetch_status": "unavailable",
"candidate": {
"title": "Synthetic item B",
"price_minor": 1200
},
"field_origins": {
"title": "provided",
"price_minor": "provided"
},
"missing_fields": [
"shipping_minor",
"stock"
],
"review_required": true,
"publish_ready": false,
"performs_action": false,
"authenticates_sources": false,
"decision": "provided_candidate"
}Name the state handed to the next screen accurately
Even a candidate with every permitted field remains review-required and never becomes publish-ready in the new module. That policy is distinct from implementing an operator review or server authorization system. A following screen can use fetch status, supplied origins and missing fields to organize its review flow. Retaining a candidate and registering an actual product externally require separate connections.
I left the original app's accounts, orders, payments, mail, collection automation and customer material unchanged. What is published is the branch found during production and a clearer independent synthetic contract. A program's website should explain which fields were filled automatically and which source material produced each candidate. Naming those states tells the reader what still needs confirmation.