v0.1.2: checkout fixes for CMS v0.2.0 #18
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: libreshop/shop#18
Reference in new issue
Block a user
Step 7 of libretech/mp#71, applied onto the v0.1.x release line (no conflicts).
alreadyCaptured) counts as success./v1/send/message; it never worked before.Verified: 51 unit tests pass on Node 22; the production image builds; 20/20 end-to-end through the shop routes against CMS v0.2.0 and a fake PayPal on the anonymised copy of 2026-10-15.
The order routes (get, put, add-product, remove-product, checkout, capture) call forwardToCms, which throws a CMS error on as createError({ statusCode, statusMessage, data: { message, errors?, missing? } }), built by the pure shopErrorFromCms (server/utils/cmsError.ts). Before, the FetchError was thrown on as it was: the browser got the CMS's status, but Nitro treated it as unhandled, answered "Server Error" without data and logged every CMS 4xx as [unhandled]. Now the browser also gets the CMS's message, the errors of a rejected update and the fields a checkout misses, and no other field. A status that is the shop's own fault (401, 403, ...) is answered 500, a CMS that does not answer 503; 5xx are logged without the query and the order uuid. npm test runs tests/unit with Node's type stripping and no dependencies, as in libreshop/cms. nuxt.config keeps tests/ out of the app's type check. Refs libretech/mp#71PUT /api/orders/:uuid forwarded the browser's body to the CMS unchanged. It now forwards { data } with only the seven fields of the checkout's steps: email, acceptedTermsAndConditionsAt, invoiceAddress, deliveryAddress, invoiceAddressStructured, deliveryAddressStructured and delivery. Any other field, a field beside data, or a body of another shape is answered 400 "Invalid order update" with the CMS's error format, without calling the CMS. The values are left to the CMS, which checks them and stays the authority; this is defence in depth. pickCustomerUpdate (server/utils/customerUpdate.ts) is pure and tested with the exact payloads of steps 1 and 2 and with every server-only attribute of the order. Refs libretech/mp#71checkoutErrorMessage (utils/checkoutError.ts) maps the status and body of a failed request, the shop's answer or a raw CMS (Strapi) error, to one fixed message for the customer, addressed with "du": an invalid e-mail address (when data.email is among the rejected fields), other invalid input, an order already paid, a product no longer available, an order not ready for checkout (naming the missing steps), a payment that does not fit the order or an order changed during the payment ("Bitte starte die Zahlung neu"), PayPal not reachable ("versuche es in ein paar Minuten noch einmal"), a payment PayPal may have taken that the CMS could not confirm or record ("Bitte bezahle nicht noch einmal"), and a general fallback. It never shows the server's text. Steps 1 and 2 show the message above their submit button, in the style of step 3's payment error, instead of logging the error only. Step 3 shows it for a failed PayPal order creation or capture. The e-mail input of step 1 is type="email" (Input.vue takes a type). Refs libretech/mp#71The CMS answers a capture of an order already paid with this PayPal order with { success: true, alreadyCaptured: true } instead of the order. Step 3 took that answer for a capture without authorisation and showed a payment error. It now reloads the paid order (keeping the shown one if the reload fails) and continues as after a first capture: confirmation, the checkout-payment-completed event, and the redirect to the order's result page. capturePayment is typed as Order | AlreadyCaptured, and the pure isAlreadyCaptured (utils/captureResponse.ts) tells them apart. Refs libretech/mp#71POST /api/contact posted { to, subject, body, replyTo } to ${mailApiUrl}/send, which the mail service (libreshop/mail src/app.py) does not have, so every message failed with a 500. It now posts { to_email, subject, message } to POST /v1/send/message, still to paperwork@muellerprints.de, with the same subject and text as before. The service sets no Reply-To; the sender's address stays in the text. A line break in the subject is replaced by a space, so it cannot start another mail header. mailApiUrl was read from runtimeConfig without being declared there, so NUXT_MAIL_API_URL could not set it and the fallback http://mail:2222 was always used. It is declared now, with that default; mp's compose.yml sets no NUXT_MAIL_API_URL. contactMail and mailSendUrl (server/utils/contactMail.ts) are pure and tested. Refs libretech/mp#71