Services marketplace with paid memberships · August 2026
Repairing a type defect the product itself wrote — through the product
What the operator asked for
In a support case on one member's account, the operator had approved a plan step: set the member's paid membership to run until 4 March 2027.
The problem
On 2026-08-21 Empasa's own apply flow wrote the membership field on that member's record as a JSON string instead of an array. The values were correct — only the container type was wrong.
It stayed invisible for four days. Earlier in the same case thread, a step had switched on the marketplace's own skip-check flag — the escape hatch that makes a broken membership field harmless. The workaround applied earlier in the thread suppressed the signal for the defect introduced later in it.
The defect was found by verifying the write itself (the stored JSON type), not the receipt. The receipt said "succeeded", and it was telling the truth.
| array | string | |
|---|---|---|
| before the repair | 5,673 | 1 |
| after the repair | 5,674 | 0 |
What Empasa did, step by step
- 1
The writer was fixed first
Only text shaped like a JSON array or object that actually parses is decoded; plain values are left untouched. Fixed on 2026-08-25.
- 2
The case was reopened from the case list
The whole thread reopens from its list row — the operator's original request, the investigation, the plan and their history.
- 3
The stored plan step still offered "Review & apply"
The record was repaired by re-running the same approved step from the same stored report. No new values, no hand-written SQL.
- 4
The approval modal: before → after, and the guarantee
The operator sees the field, the current value and the new value before approving — and the line "Reversible — creates rollback receipts".
The approval modal. The member line is masked. - 5
A reason, recorded on the audit receipt
Optional, but kept with the receipt — so the audit trail says why, not just what.
The reason entered before applying. The member line is masked. - 6
"Applied 1 change across 1 user"
The plan step is marked applied, with the exact before → after value and "Reversible — backup saved".
The applied plan step.
Why a re-apply, and not a manual fix
- It stays inside the product's own tooling, so the write gets a backup, an audit receipt and a rollback.
- The identical action producing a different stored type is itself the proof that the writer fix is live.
Verified after
- ✓The stored type of the membership field is now an array.
- ✓Its array length is 1 — a check that would throw on a string.
- ✓Inside it: status "active", end date 2027-03-04T23:59:59.999Z, payment gateway "paypal".
- ✓The membership level label — intact.
- ✓The skip-check flag — intact.
- ✓The rollback payload captured the real prior value (the string), so the change is genuinely reversible.
One honest defect this run surfaced
The modal's before → after preview showed [null] → [{…}]. [null] was the value as of 2026-08-21, when the report was written — the live record held the string. The preview's "from" comes from the report's stored current value, not from a live read.
The executor read the record correctly — the rollback receipt proves it — so the write and its reversibility were sound.
Harmless here, but the operator approved against a stale "before", which is exactly the class of thing this card exists to prevent. Filed as a defect: the approval modal should show a live "from", or say plainly that the before-value is as of report time.