Entry 1: Full ticket editing and the trap of empty parameters
Deploying full ticket editing to the testing environment naturally brought a few unexpected surprises that needed immediate attention. When you try to push completely empty parameters into the system via an update PATCH request, the system shouldn't immediately collapse with a 400 error. Instead, I had to adjust the application's behavior so that it passes without unnecessary panic, while finally allowing the clean removal of a specific resolver.
Another small but significant snag was hiding in the detection of changes to the ticket's status itself. I had to add a specific test lock so the system wouldn't just do whatever it wants when it encounters a foreign identifier. Every removed detail like this makes the difference between a smooth run and the frustration of end users.
Leaving aside these technical dodges and the testing around a specific ticket, the production web quietly breathed the whole time and responded normally after my interventions. This is exactly what quiet but effective work looks like.