Add secure server-side behavior

Use a server function for trusted permission checks, validation against saved data, or controlled multi-step updates. Security-sensitive decisions cannot rely on a hidden button or browser-supplied value.

Request one narrow action

Describe who can run the function, its input, its allowed state change, its result, and the failures the app must handle. Also say what should happen if the same request arrives twice.

For example:

Add a server-side action that confirms a booking. Only a signed-in staff member may run it. It receives a booking ID, checks that the booking exists and is still pending, changes its status to confirmed, and returns the updated booking. If it is already confirmed, return the current result without creating another change. Reject cancelled bookings and unauthorized users with useful messages.

Keep the contract specific. One named business action is easier to protect than a general endpoint. The page must wait for the result before showing success.

Test success and failure

After the build completes, test:

1. a pending booking with an authorized account;
2. missing or invalid input;
3. a signed-out and an unauthorized request;
4. the same valid request twice;
5. an already cancelled booking.

The valid request should produce one state change. Invalid or unauthorized requests should change nothing. A repeat should return the known result or a clear conflict rather than duplicating work. Refresh the app and inspect the saved booking to confirm the final state.

Open Runtime → Functions and select the same environment. The pane shows the declared function inventory and reported runs. Compare the function name, start time, and status with the action you just tested. If no run appears, first check the selected environment and whether the page actually sent the request.

Handle uncertainty safely

Use messages that distinguish input a person can correct, lack of permission, a state conflict, and a temporary failure. Do not expose stack traces, credentials, or internal details. Function inspection and logs should identify the operation without recording passwords, sessions, tokens, or unnecessary personal information.

When the browser does not know whether a request finished, show an uncertain state and let the person check the saved result before retrying. Test the published function separately in Production; a successful development run does not establish production behavior.