Appearance
Known issues
Page summary: See product risks without mixing them into normal product behaviour.
Use this when: Internal register for triage, prioritisation, and workaround awareness.
- Severity is consequence; confidence is evidence strength.
- A code finding is not automatically a reproduced fault.
- Every real issue should gain an owner, decision, and ticket.
Product health register. Not customer-facing, and not to be shared outside Delta.
Nothing here was reported by a customer. All of it was found by reading the code and checking dev while writing this handbook. That means the list is unusually complete for its age — and unusually unverified.
Every entry needs an owner and a decision. Until one has both, it is a finding, not a fault.
Opened 5 August 2026. No entry has been triaged yet.
How to read this
Severity is about consequence if the issue is real, not about how likely it is.
- High — money is wrong, capacity is wrong, or a customer sees something false
- Medium — someone is misled, or a number in a report is wrong
- Low — confusing, but nothing downstream breaks
Confidence: is separate. Several high-severity entries are code readings only.
High
Bookings can exceed capacity
Impact: Two guests can take the last place. Nothing refuses it.
Detail: The main booking route's capacity check is commented out, marked "disabled as per request". The partner route checks but keeps one yes/no answer for the whole booking, so a full item passes if any other item is free. The database has no rule either. Editing a booking skips the check too, in every environment.
Confidence: Confirmed in code, every possible guard checked. Not reproduced.
Support workaround: None. Vendors must watch their own numbers.
Owner: unassigned · Ticket none · Rule bookings can exceed capacity, the partner route checks loosely
A cancelled booking can be reopened through the API
Impact: Seats, payment schedules and promotions are not restored. Product has stated this must not be possible.
Detail: The dashboard blocks it. The service does not.
Confidence: Confirmed in code.
Support workaround: Do not do it. There is nothing to stop someone calling the API directly.
Owner: unassigned · Ticket none · Rule a cancelled booking cannot safely be reopened
Commission-as-discount does not do what it looks like
Impact: A money difference on partner bookings, silently.
Detail: The setting tries to force the calculation to "from gross", but changes the value after it has already been copied. The line has no effect.
Confidence: Confirmed in code.
Support workaround: None.
Owner: unassigned · Ticket none · Rule commission as a discount does not work
"Net" means two different things
Impact: Whoever agrees a commission rate with a partner is agreeing to one of two different numbers, and the contract will not say which.
Detail: In the ordinary calculation, "from net" means after the platform fee, tax still included. In the partner calculation it means after tax.
Confidence: Confirmed in code.
Support workaround: Check which partner model the deal uses before quoting a number.
Owner: unassigned · Ticket none · Rule "net" means two different things
A fully refunded invoice document says "Unpaid"
Impact: The document goes to the customer and is what finance reconciles against. The badge on screen is correct; the PDF is not.
Detail: Only four invoice statuses have a word of their own. Draft, partially refunded and fully refunded fall through to "Unpaid". The PDF is rebuilt on download, and a refund changes the invoice.
Confidence: Confirmed in code. No refunded invoice PDF has been opened.
Support workaround: Tell the customer the screen is authoritative, not the document.
Owner: unassigned · Ticket none · Rule a refunded invoice document says "Unpaid"
Negative vendor income is turned positive
Impact: A misconfigured partnership that should show a loss shows a plausible profit instead. Nobody finds out.
Confidence: Confirmed in code.
Support workaround: None.
Owner: unassigned · Ticket none · Rule negative vendor income is turned positive
The two systems disagree on the word for a full refund
Impact: The dashboard would not recognise the value, so the payment status shows with no label and no colour.
Detail: The service sends refunded; the dashboard expects fully_refunded. Four values the dashboard handles do not exist at all, and unpaid is not handled.
Confidence: Confirmed in code. Not seen on screen.
Support workaround: None needed until seen.
Owner: unassigned · Ticket none · Rule the dashboard expects payment values the service never sends
Some status changes do nothing and report success
Impact: The automatic cancellation job uses this route. A booking at requested would fail to cancel and log success.
Confidence: Confirmed in code. Not reproduced.
Support workaround: Re-read the booking after changing its status.
Owner: unassigned · Ticket none · Rule some status changes do nothing
Medium
Vendor bookings skip every check
Impact: A vendor can overfill a slot with no warning, at any price, and the slot's approval setting is ignored.
Detail: Probably deliberate, for walk-ins and phone bookings. Never written down.
Confidence: Confirmed in code.
Owner: unassigned · Rule vendor bookings skip every check
Rejected bookings get a confirmation time
Impact: Any report counting confirmations by that field counts rejections too.
Confidence: Confirmed in code.
Owner: unassigned · Rule rejected bookings get a confirmation time
The status guide explains a status that does not exist
Impact: A vendor looking up the status in front of them will not find it. Waiting payment — where every booking starts — is not described at all.
Confidence: Confirmed in dev. The only entry on this list seen with our own eyes.
Support workaround: Explain it directly; do not send them to the guide.
Owner: unassigned · Rule the status guide explains a payment status that does not exist
The dashboard and the service keep separate transition rules
Impact: What you can do depends on whether you go through the screen or the API. The screen is currently the only thing preventing the cancelled-booking issue above.
Confidence: Confirmed in code.
Owner: unassigned · Rule the dashboard keeps its own copy of the transition rules
A booking status nothing can display
Impact: partially_confirmed is accepted as valid but unknown to the dashboard. Nothing sets it today.
Confidence: Confirmed in code.
Owner: unassigned · Rule a status nothing can display
Low
| Issue | Impact | Confidence | Rule |
|---|---|---|---|
unpaid fails the service's own validity check | Defined, then left out of the valid list | Confirmed in code | a payment status that fails its own validity check |
concierge fails the same check | Same pattern | Confirmed in code | Words we use |
| A rounding switch that does nothing | Both branches identical | Confirmed in code | the rounding switch does nothing |
| The rounding helper is misnamed | Rounds half up, called round-up, wrong for negatives | Confirmed in code | rounding is not what it is called |
| "Requires approval" means two unrelated things | Approving a booking, and approving an experience for a partner | Confirmed in code | "requires approval" means something different here |
Not on this list
Two things were found while writing the handbook that are not product faults and are not tracked here:
- Database and partner passwords are committed in plain text in the backend configuration files, including production.
- Staging is configured to use the development partner password and the beta payment service.
Both were raised directly. They belong with whoever owns infrastructure, not in a product register.
What happens to an entry
It leaves this list when it is fixed, or when someone decides it is intentional and the rule page records that intent. An entry sitting here for months with no owner is itself the problem.