I, for one, am sick of "just run the Docker image" as a deployment strategy and the be-all end-all of support. On my last attempt at serving a photo gallery, I deployed Hetzner's Photoprism image on a Hetzner server... and it failed. You would think such a thing would be bulletproof! They don't tell you an IPv4 address is needed and the log does not indicate anything is wrong other than Traefik has problems connecting to the certificate server.
If something doesn't work—regardless of how unhelpful the report or oddly configured the deployment machine is—I would love to hear about it so I temper my own expectations before trying it myself.
While I sympathize with the developer whose product is popular enough to collect 1000 issues as of two days ago, some of your many thousands of users can also get fatigued by spending resources (time, money, mental effort) on deployments that fail because the machine and network running Docker is still different enough from yours that issues arise.
My Hetzner Photoprism bug report has been sitting unanswered for two weeks. Getting the log data and trying out different DNS configurations and writing the bug report took a few hours, because I had to SSH into the Docker image and run curl verbosely and figure out which of the five docker-compose elements was causing problems; running Docker and setting up servers isn't my day job. I don't feel like paying 25 bucks a year for an IPv4 address and don't really want to figure out how to get Let's Encrypt to work on Hetzner's IPv6 by manually adjusting the Docker Compose configuration. I thought that's the point of Docker Compose: that you wouldn't need to dick around with it to get it working. I'll probably delete the thing and replace it with something else—potentially Nextcloud as there's no preconfigured Immich image. So, you know... expect my Memories bug report in a few days.
I can't imagine this user's complaint was fabricated from thin air. Rude or not, they are having problems with the thing you made. Make a mental note, "at least some small percent of users are still having issues, in this case no clear root cause, probably a small enough population to ignore, maybe one day further reduce the friction for reporting bugs or find a way to gather more detailed info." Maybe put them in their place if they actually attack you personally or actually have no useful information e.g. "Product Sucks!!" but beyond that, I (as a potential fellow user) find these not-very-dev-helpful reports insightful, as there are two dozen competing FOSS photo storage programs and I want to efficiently figure out which application has features I prefer, is actually stable and easy to deploy, not likely to switch licenses going forward, has a clear goal and steady progress, documentation is well-written and not just a "Brothers Karamazov" dump of one developer's stream of consciousness, etc.
Should I take two or three hours to file bug reports for each of the 20 photo albums I'd consider testing instead of spending time with family or practicing music? Maintainer fatigue is no joke, but it's also a burden on users if the software does not run, and they've already sunken some opportunity cost, and then not every user knows how to be kind and helpful through their frustration.
Anyway, your reaction is valid. I hope you keep working on the project, but I'd also be okay with not having so many different FOSS options and still no clear winner.