Controlled demonstration / AFK³ Solutions
The app says saved,
but the ticket disappears.
A synthetic service-ticket workflow with a deliberately introduced persistence defect. Inspect the diagnosis, try the behavior and compare the repair.
Prepared by AFK³ Solutions · 2 November 2026 · Demonstration, not customer work
What this demonstrates
A success message is not proof of a saved record.
A service coordinator creates ticket DEMO-001. The broken save method returns success after placing the ticket in temporary memory. The record list reads the durable repository, which never received that write.
The cause in this demonstration is a missing persistence step. The repair waits for the repository write before acknowledging success and propagates write failures. A real app can show the same symptom for different reasons, so this is an example of an investigation, not a universal fix.
All records are synthetic. No customer incident, delivery-time claim or business result is implied.
Try the workflow
Compare the broken and repaired behavior.
This interactive version runs in your browser. It uses browser storage, makes no ticket-network requests and accepts no customer information. The same workflow functions are exercised against a file-backed repository in separate Node tests.
Enable JavaScript to use the interactive demonstration. The diagnosis and checks below remain readable.
Saved records
Interactive records appear here.
- Reset the demo. Choose Before repair, save the ticket and reopen the workflow. No record is stored.
- Choose After repair, save and reopen. DEMO-001 remains in the saved list. A browser refresh also reads the same browser-stored record.
- Reset, choose After repair, enable the write failure and save. The error is reported without acknowledging success.
The reset affects only this demonstration’s browser-storage keys. If your browser blocks storage, the simulation reports that limit.
Sample diagnosis
What we found and how we checked it.
| Check | Before | After |
|---|---|---|
| Save and open a fresh workflow instance | Success returned; repository empty | Stored ticket returned |
| Save the same ticket ID again, sequentially | No durable record | Existing record updated; one ticket retained |
| Repository rejects a write | Missing write hides the failure | Error propagated; no success acknowledgement |
The Node regression checks use a temporary directory and a real file repository. They recreate the workflow and adapter after saving, so the persistence assertion does not rely on an in-memory copy. The temporary files are removed after each test.
Limits of this evidence
This is a small, single-process demonstration. It does not establish production database durability, concurrent-writer behavior, authorization, tenant isolation, migration safety, backups, email delivery or deployment readiness. Browser-storage checks and file-repository checks are distinct. A production repair needs checks appropriate to its actual stack and environment.
Inspect the workflow code →
Inspect the file adapter →
Inspect the regression checks →
Your app, your workflow
Bring the behavior you need to verify.
Tell us which task fails, the expected and actual results, the stack and the business impact. We agree on one workflow, the investigation budget and deliverables before paid diagnosis. Repairs and support are scoped separately.
Discuss an App Review →