Undo a change

We found the preview failure in one dedicated commit. We'll undo that commit, deploy the correction, and check that sending works again. Git can record the reversal alongside the original change, giving us a clear recovery history.

In the website folder, check the branch and recent commits:

git branch --show-current
git status
git log -4 --oneline

The branch must be form-recovery, and the working tree should be clean. Keep the failure commit identifier from 5.3 available. If the branch or local changes differ, resolve that before continuing.

Outcome

Revert the known failure commit and verify the corrected preview without discarding unrelated work.

Hands-on exercise 5.4

Identify what to reverse

A revert creates a new commit that undoes the changes from a selected commit. The original stays in the history, so we can see both the mistake and its correction, even after sharing the work.

Inspect the exact commit from our diagnosis. Replace the placeholder with its recorded identifier:

git show --stat PASTE_FAILURE_COMMIT_HERE
git show PASTE_FAILURE_COMMIT_HERE -- app/actions/interest.ts

The patch should contain only the preview-only key expression from 5.3. If it includes other work, stop and identify the correct dedicated commit. Selecting whatever happens to be the latest commit could reverse something unrelated.

Keep the production branch untouched during this exercise. The failure and its correction both belong on the recovery branch; production already has the working email configuration.

Create the correction

With the right identifier and a clean working tree, run:

git revert --no-edit PASTE_FAILURE_COMMIT_HERE

--no-edit accepts Git's generated revert message, which references the original change. This command writes a new commit. It doesn't delete earlier history or require a force push. See Git's revert documentation for the command's behavior.

Inspect the new commit and the action file:

git log -2 --oneline
git show --stat HEAD
git diff HEAD~1 HEAD -- app/actions/interest.ts

The correction should restore apiKey: process.env.RESEND_API_KEY. The catalog still contains all three workshops because their release preceded the failure commit and isn't part of its patch.

If Git reports a conflict, read the troubleshooting guidance below. Don't use a reset to force the history back to an earlier point. We want to reverse this one intentional edit while keeping other saved work.

Verify before deploying

Run the existing email-helper tests from 4.5:

npx tsx --test tests/course-interest.test.ts

Use the pnpm equivalent when appropriate. These tests check that the helper still handles the fake senders' results correctly. Inspect the adapter diff as well: the unit tests don't prove that a deployed environment supplies its settings correctly.

Open the local site if needed and confirm the three catalog entries remain. Check git status before deploying so the preview represents the saved correction.

Deploy the recovered version

Run vercel and copy the new preview URL. Confirm that it belongs to the existing workshop project and uses the recovery commit. Open the new URL; the failed preview URL still identifies the older deployment.

Submit one controlled inquiry on the corrected preview. Check the acceptance message and owner inbox. If it remains unconfigured, inspect Preview's environment values and the deployment source before making another code change.

The new preview is the version we use to verify the recovery. Keep the failed URL in your private exercise notes as evidence of the earlier state, but don't share it as the current working site.

Try It

Compare the failure and recovery notes. Record the original failure commit, its revert commit, and the corresponding preview URLs. Include the controlled delivery observation for the corrected deployment.

Return to the released branch after verification:

git switch main
git status

Substitute your actual production branch if needed. Leave form-recovery available as exercise history. It doesn't need to be merged because the production branch never received the intentional failure. Confirm production still points to the release from 5.2.

Revert reports a conflict

A later edit may overlap the selected change. Git identifies the conflicted files with git status. For this exercise, git revert --abort cancels the in-progress revert and returns to the pre-revert state. Inspect the branch history and choose the correct commit before retrying. If a conflict needs manual resolution, review that specific overlap before continuing the revert.

The new preview still fails

Check that the browser is on the corrected deployment URL. Inspect the deployed source identifier and confirm Preview still has the email configuration from Section 4. A provider rejection and a missing key have different runtime events; use the observed event to guide the next investigation.

Commit

git revert has already created the correction commit. Don't add an empty commit afterward. Keep its identifier with the diagnosis and preview evidence. For a shared release, we'd review and deploy this correction the same way as any other code change.

Done-When

• The selected failure commit is reversed by a new commit on form-recovery.
• The diff restores normal key lookup and preserves the three-workshop catalog.
• The corrected preview accepts an inquiry that reaches the owner inbox.
• The recovery is documented and production remains on its working release.

Solution

After inspecting the recorded failure identifier, the recovery sequence is:

git revert --no-edit PASTE_FAILURE_COMMIT_HERE
git status
npx tsx --test tests/course-interest.test.ts
vercel

Replace the identifier placeholder and use the project's package manager. Review the new preview, verify the controlled send, then return to the production branch. Keep the saved diagnosis with the release notes for the workshop site.