Skip to content

M3-16 Test Evidence (D4b)

Milestone: M3 — Issuing Functionality SOW Reference: Deliverable D4b Requirement Clarity: ✅ Clear Dev Status: ❌ Automated tests still not started (unit/integration suites — same gap as M2-14). A full manual, live end-to-end pass of issuance → claim was run 2026-09-02 against real Velocity staging and real AWS SES, covering every fix from today's QA batch — see below. That's real evidence the flow works, but it's not a substitute for the automated regression suite this deliverable actually asks for.

Update 2026-09-02 — end-to-end issuance → claim test, live environment

Ran the full pipeline against the local dev backend, wired to the real Velocity CIH staging API and real AWS SES (not mocks), using the TESCO LLC test organisation (c979a997-..., tenant ACTIVE on Velocity). Purpose: confirm today's fixes (intermittent 400 on issuance, Send Test 400, false "Sent" status, Resend being a no-op) actually hold under real conditions, and walk the whole issuance → claim journey once end-to-end. Done via direct API calls (dev JWT bypass), not by clicking through the browser — no authenticated browser session is available in this environment, so the frontend forms themselves are untested here; everything below exercises the same backend code the frontend calls.

1. Issuance, full field set, deliberately awkward input. Issued an EmploymentPastV1.1 credential with a job title and role description containing quote marks and a line break (Senior "Lead" Engineer, a multi-line role description) — exactly the kind of text that broke issuance intermittently before today's fix. Result: 201, real credential minted on Velocity (vnfCredential.id, real deep link, real depotId), quotes and line break preserved correctly in the compiled credential. Confirms the JSON-escaping fix.

2. Real SES sandbox rejection, correctly surfaced and correctly persisted. The same request used a recipient address that isn't a verified SES identity. Response came back emailSent: false with the exact SES rejection reason (554 ... Email address is not verified ... AP-SOUTH-1) — and, checked directly in the database, the offer's status was created, not sent. Before today's fix this would have shown "Sent" in Credentials History despite the email never leaving SES. Resend was then correctly offered as available on this record.

3. Claim landing page, before and after. GET /claim/:token on the unclaimed offer returned the full candidate/employment/deep-link payload needed to render the claim page, independent of the offer's created (not sent) status. Simulated the claim itself, then re-fetched: status flips to claimed with claimedAt set, and the same GET now returns success: true, alreadyClaimed: true with the full data payload rather than a bare error — confirms the claim-page fix holds (a reload or a second tab landing on an already-claimed offer gets the success view, not a scary error). A second claim attempt against the same token is correctly rejected ("Credential has already been claimed") — the backend route the old "Claim via web" button used to hit still guards against double-submission even though nothing in the current UI can trigger it anymore.

4. "Send Test" from the templates list. Posting to the saved-template test-send route with a templateId alongside the body — the exact shape the templates list UI sends — no longer 400s on property templateId should not exist. It now correctly proceeds to the real send attempt and fails only for the same SES reason as above, on both an unverified address and, notably, the one address documented in .env.development as SES-verified (devadmin@neuralrays.ai) — that address was rejected too. New finding, not yet actioned: either that verification has lapsed or the documented setup is out of date; whoever owns the AWS account should re-check SES Verified Identities before assuming any address currently gets through, including the "known-good" one referenced in the env file comments.

5. Resend, made real. resendCredential previously flipped an offer straight to sent without attempting a send at all (its own comment referenced an "email-retry flow" that doesn't exist in the codebase). Called Resend on a created (failed-send) offer: it now genuinely attempts delivery, gets the same real SES rejection, returns a clear 400, and — checked in the database — the offer stays created, not falsely flipped to sent. Also confirmed the pre-existing guard still works: Resend on the already-claimed offer from step 3 is correctly refused ("Cannot resend a claimed credential").

Not testable here — needs a real wallet: the actual candidate-side claim (scanning the QR/deep link with a Velocity-compatible wallet app) and ClaimSyncService's 5-minute poll picking up a real wallet acceptedAt weren't exercised — that requires a physical wallet app, not just an API client. Step 3 above simulated the claim through the same backend endpoint the old "Claim via web" button used, which exercises the same status-transition code but isn't proof the poll-based detection (the only live mechanism now, per M3-06) fires correctly on a genuine wallet claim.

Minor naming note, not a defect: the claim page's employment.department field (both in the API response and the candidate-facing summary line) actually carries the combined department + role description text since the 2026-09-01 schema consolidation, not department alone — the displayed content is correct, the field/variable name is just stale. Cosmetic; not fixed here to keep this pass scoped to verifying today's actual bug fixes.

Test data created by this pass (TESCO LLC org, candidates "Alex QA-E2E" and "Sam QA-Resend") is local-dev-only — real Velocity staging records, but not visible to the client and not on the shared dev-curorec.duckdns.org environment.

Overview

Produce the Test Evidence deliverable for M3's scope: test results, logs, and defect summary for the issuing functionality.

Tasks

  • Write unit tests for credential template, issuance, claim, and reminder services
  • Write integration tests for the Velocity Credential Agent integration
  • Produce test summary/logs and a defect log per Appendix 3

Dependencies

  • Runs alongside all M3 build tasks.

Acceptance Criteria

  • Test evidence complete and traceable to scope (per SOW Appendix 3, D4b)

Existing Reference Material

None — confirmed gap.

Blockers & Risks

  • Risk: same as M2-14 — this is real effort, not documentation of pre-existing tests.