RequestHunt is a community-driven platform that collects and curates feature requests from X (Twitter), Reddit, and GitHub. We help product teams discover what features real users are asking for, making it easier to validate product ideas and prioritize feature development based on actual user demand.

How does RequestHunt collect feature requests?

RequestHunt uses AI-powered extraction to automatically collect feature requests from social media platforms including X, Reddit, and GitHub. The platform monitors discussions, issues, and posts to identify genuine user feature requests, extracting key information like the requested feature, product mentioned, and user sentiment.

Who uses RequestHunt?

RequestHunt is used by product managers, founders, developers, and product teams who want to discover what features real users are requesting. It's particularly valuable for startups looking to validate ideas, established companies prioritizing their roadmap, and developers building products that solve real user problems.

Is RequestHunt free to use?

Yes, browsing and searching feature requests on RequestHunt is completely free. We also offer API access for developers who want to integrate feature request data into their own applications. Check our pricing page for API plan details.

How often is RequestHunt data updated?

RequestHunt continuously collects feature requests from Reddit, X (Twitter), GitHub, YouTube, LinkedIn, and Amazon. You can also trigger on-demand scraping via the API or web interface to get the freshest data for any topic.

[Azure] Enable canary deployments for message-based microservices

The user is looking for a way to implement canary deployments for their microservices that communicate via Azure Service Bus. They want to limit the impact of bugs that slip into production when new revisions are deployed, but the current setup does not allow for traffic direction to specific revisions for message processing. They seek a solution or feature that would allow this capability.

Original Source

@u/Confident-Review-599 | 2 pts | 3/13/2026

Hey We are currently looking into canary deployments (we already have good guard rails, automated tests, etc..). Now we want to limit blast radius of those bugs that still slip into production by doing canary deployments. We have a microservice architecture with container apps on Azure. With container apps you can decide how mush traffic a certain revision receives which is great for canary deployment. This works great for http endpoints on the container app. The problem however is this: A lot of the communication between container apps are message based using Azure service bus. This does not allow a subset of traffic to be directed to one or the other revision. From the moment a second revision is up it will start processing messages from service bus immediately (even if revision traffic is set 0%). If this revision would contain a bug in the way it processes said messages, customers are impacted. How do people still allow canary deployment in this scenario? Start writing your custom solution? I've tried looking for a solution online but don't find any satisfying answers.

Discussion

Loading comments...