feat(npqs): send the trader's documents with the ePhyto certificate - #59
feat(npqs): send the trader's documents with the ePhyto certificate#59Aravinda-HWK wants to merge 1 commit into
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The certificate named no supporting documents, so a treatment certificate or invoice the trader had uploaded reached the importing NPPO as nothing at all. The submission form now asks which documents to send, the macro workflow passes each upload's storage key down to the ePhyto step, and the submit node receives both the keys and the trader's answers. Every toggle is optional: a consignment that skipped the treatment branch simply has no key to map, and the step sends what exists — a tick naming a document that was never uploaded is ignored rather than refused. The submission node's output_mapping carried only hub_destination, so the six answers never reached the workflow variables the submit node reads and every document resolved to "no" however the trader answered. They are mapped now, which is what makes the selection take effect. The poll node also wrote its results into the ephyto namespace, where each check overwrote the submit node's tracking number. It writes to ephyto_poll instead, and the delivery-status pages read from there.
0af57c8 to
745cab0
Compare
There was a problem hiding this comment.
Please check: the document-selection wiring (macro keys, submission output_mapping for the six toggles, submit input_mapping) matches what OpenNSW/nsw-srilanka#386 reads, and the description of that half is accurate. The poll rename is not.
StartSubTask loads npqs-ephyto-upload--poll from the registry on every poll (subtasktemplate.Load by id). It does not snapshot the template with the child workflow. soap_call then writes the result into Record.Data[output_namespace] and returns the whole Record.Data as the activity result. v8 of npqs-ephyto-upload (what any in-flight ePhyto child is already running) still has a required output_mapping of ephyto.delivered. After this recreate:
- A consignment that has submitted but not yet polled has no ephyto.delivered key. The next poll writes ephyto_poll instead, mapTaskOutputs fails with "required task variable 'ephyto.delivered' not found", and the child workflow errors.
- A consignment already in the poll loop may still have a stale ephyto.delivered=false from the last pre-deploy poll. New polls update ephyto_poll, the v8 gateway never sees delivery, and the loop runs to the 1440-check timeout.
The description presents the rename as an isolated UI fix for the tracking-number clobber. That clobber is real (soap_call replaces the namespace wholesale, which is why the polling page lost the number), but changing a live subtask_template namespace is not how to fix it while v8 children can still be running.
Suggested fix: leave poll.json output_namespace as ephyto, and revert the ephyto_poll mappings in 9-ephyto/workflow.json plus the three markdown templates. Preserve tracking_number by merging the poll result into the existing ephyto object in the SOAP plugin (nsw-srilanka#386) instead of replacing it. Keep the document-selection mappings; those are a new child graph (v10) and do not have this live-template problem.
If you keep the ephyto_poll split anyway, drain every in-flight npqs-ephyto-upload child before recreating tnsw-api. New flows would be fine; in-flight ones would not.
2 participants
Summary
The ePhyto certificate named no supporting documents, so a treatment certificate or invoice the trader had uploaded reached the importing NPPO as nothing at all. This wires the selection through the NPQS flow.
Pairs with OpenNSW/nsw-srilanka#386, which reads these artifacts — neither half does anything alone.
Changes
tnsw/npqs/9-ephyto/submit_form.json— the submission form asks which documents to send: the application's own attachments, the treatment certificate, the supervision report, the invoice, the packing list, and the additional supporting document.tnsw/npqs/npqs_workflow.json— the macro workflow passes each upload's storage key down to the ePhyto step. Every mapping is optional (?): a consignment that skipped the treatment branch has no key to map.tnsw/npqs/9-ephyto/workflow.json(v8 → v10)submitnode now receives both the storage keys and the trader's answers.submissionnode'soutput_mappingcarried onlyhub_destination, so the six answers never reached the workflow variables thesubmitnode reads, and every document resolved to "no" however the trader answered. Mapping them is what makes the selection take effect at all.pollnode wrote its results into theephytonamespace, where each check overwrote the submit node's tracking number. It writes toephyto_pollnow, and the delivery-status pages read from there.The form offers every document the flow can produce, whichever path the consignment took. A tick naming a document that was never uploaded is ignored by the submit step — there is nothing to attach and nothing to refuse — so the certificate carries the selected documents that exist and nothing else.
Testing
Ran end to end against the IPPC UAT Hub: the envelope was accepted with the invoice and packing list the trader selected inside the certificate, and a ticked toggle for a document the consignment never produced was skipped without failing the submission.
All seven files parse as valid JSON.
npqs_workflow.jsonis a five-line addition; the reformatting an editor had introduced is not included.Deploying
The artifact registry is read at boot —
tnsw-apineeds a recreate for these to take effect.