Running sp_QuickieStore @include_plan_ids = 2, @include_query_ids = 2 seems to fail absolutely everywhere

[ReeceGoding]

Version of the script
4.2

What is the current behavior?
I'm suspicious of the count_executions column in sp_QuickieStore's output. I have a query that happens to have both query_id and plan_id 2. Filtering for query_id = 2 OR plan_id = 2 in the query_store_plan view returns exactly one row, there is only one row for this query in query_store_query, and filtering for plan_id = 2 in query_store_runtime_stats returns over 300 rows all with big but varying count_executions values. Despite this, both sp_QuickieStore @include_plan_ids = 2 and sp_QuickieStore @include_query_ids = 2 thought that the query has only run four times. I tried adding various other arguments, e.g. @expert_mode = 1, @debug = 1, @start_date = 20240101, @end_date = 20241201, but at best they gave me no new information and at worst they reported that the query had only run two times. That said, the #query_store_runtime_stats temp table has what looks to be the right content if I specify @include_query_ids, but this doesn't find its way in to the first table that is returned.

This issue came from my final idea for fixing the above problem: I ran sp_QuickieStore @include_plan_ids = 2, @include_query_ids = 2. This fails at runtime in every database I have tried it in.

offending query:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT DISTINCT
    qsq.plan_id
FROM [my_database].sys.query_store_plan as qsp
WHERE EXISTS
   (
        SELECT
                 1/0
        FROM #include_query_ids as iqi
        WHERE iqi.query_id = qsp_query_id
   )
OPTION(RECOMPILE);

Msg 2627, Level 14, State 1, Procedure sp_quickiestore, Line 2642 (Batch Start Line 0)
Violation of PRIMARY KEY constraint 'PK_#include_[...]'. Cannot insert duplicate key in object 'dbo.#include_plan_ids'. The duplicate key value is (2).

This strikes me as a bug. I do not think that I am mixing these parameters in an unusual way. If I am, then this should fail long before the point where a primary key violation kills it.

If the current behavior is a bug, please provide the steps to reproduce.
I can trigger this error on every database I've tried. I presume that simply running sp_QuickieStore @include_plan_ids = 2, @include_query_ids = 2 anywhere is sufficient. If not, then my above story about the odd execution counts might be helpful.

What is the expected behavior?
Presumably, the procedure shouldn't fail.

Which versions of SQL Server and which OS are affected by this issue? Did this work in previous versions of our procedures?
I'm on SQL Server 2019.

[erikdarlingdata]

@ReeceGoding thanks for reporting this. There was indeed a bug when using both the @include and @ignore flavors of those parameters. The simplest solution seems to be to add the IGNORE_DUP_KEY option to the clustered primary keys on those two temporary tables.

As for the count_executions thing, that is raw data -- I don't do any counting or grouping -- you may want to review how the where clause ends up.