fix: remove label filter from issue dedup query

[Hweinstock]

Description

The dedup logic in ci-failure-issue.yml filtered by labels (high-severity,ci) when checking for existing issues via listForRepo. If the token creating the issue does not have permission to apply labels, the issue is created without labels. On subsequent runs, the dedup query cannot find it (because it filters on labels that were never applied), causing duplicate issues.

This PR removes the labels parameter from the listForRepo call so dedup relies solely on title matching.

Related Issue

N/A — discovered during CI workflow re-runs.

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

Re-run the CI failure workflow and verify it does not create a duplicate issue when one already exists (regardless of whether labels were applied).

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

No source code changes — workflow-only fix. No unit/integ tests apply.

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[agentcore-cli-automation]

Thanks for the fix — the root cause analysis is correct. I have one concern about the new dedup query that I think should be addressed before merging.

The repo currently has ~85 open issues and ~44 open PRs (≈129 total). Since listForRepo returns issues and PRs (PRs count as issues in this endpoint) and this call fetches only the first page with per_page: 100, the CI failure issue being deduped against will fall off the page as soon as there are >100 newer open issues/PRs. The previous labels: 'high-severity,ci' filter kept the result set small enough that a single page was always sufficient; removing it makes the existing single-page limitation a real correctness problem right now, not a theoretical one.

See the inline comment for options.

[agentcore-cli-automation]

The switch to the search API addresses the >100-issues pagination concern from my previous review — thanks for iterating on this.

I have one remaining concern: the GitHub search API has a well-known indexing delay (typically seconds to a minute or more) between when an issue is created and when it becomes findable via search. This reintroduces a duplicate-issue risk that the previous listForRepo approach did not have, because listForRepo reads from the primary datastore and reflects newly-created issues immediately.

See inline comment for details and a couple of options.

[agentcore-cli-automation]

The hybrid approach addresses both previous concerns cleanly:

• The search API handles the general case efficiently regardless of repo size, solving the >100 issues/PRs pagination problem from the first review.
• The listForRepo fallback sorted by created desc with per_page: 30 covers the search-indexing-delay race window from the second review — a freshly-created issue will be at the top of the recently-created list, well within 30 items even accounting for concurrent PR activity.

The exact-title check i.title === title on both paths correctly compensates for the substring behavior of search's in:title and also makes the fallback robust against PRs with similar titles (since listForRepo returns both issues and PRs).

workflowName is validated against /^[A-Za-z0-9 _()\-]+$/ before being interpolated into the search query, so no injection concern.

LGTM.

[Hweinstock]

Description

The dedup logic in ci-failure-issue.yml filtered by labels (high-severity,ci) when checking for existing issues via listForRepo. If the token creating the issue does not have permission to apply labels, the issue is created without labels. On subsequent runs, the dedup query cannot find it (because it filters on labels that were never applied), causing duplicate issues.

This PR removes the labels parameter from the listForRepo call so dedup relies solely on title matching.

Related Issue

N/A — discovered during CI workflow re-runs.

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

Re-run the CI failure workflow and verify it does not create a duplicate issue when one already exists (regardless of whether labels were applied).

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

No source code changes — workflow-only fix. No unit/integ tests apply.

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[agentcore-cli-automation]

Thanks for the fix — the root cause analysis is correct. I have one concern about the new dedup query that I think should be addressed before merging.

The repo currently has ~85 open issues and ~44 open PRs (≈129 total). Since listForRepo returns issues and PRs (PRs count as issues in this endpoint) and this call fetches only the first page with per_page: 100, the CI failure issue being deduped against will fall off the page as soon as there are >100 newer open issues/PRs. The previous labels: 'high-severity,ci' filter kept the result set small enough that a single page was always sufficient; removing it makes the existing single-page limitation a real correctness problem right now, not a theoretical one.

See the inline comment for options.

[agentcore-cli-automation]

The switch to the search API addresses the >100-issues pagination concern from my previous review — thanks for iterating on this.

I have one remaining concern: the GitHub search API has a well-known indexing delay (typically seconds to a minute or more) between when an issue is created and when it becomes findable via search. This reintroduces a duplicate-issue risk that the previous listForRepo approach did not have, because listForRepo reads from the primary datastore and reflects newly-created issues immediately.

See inline comment for details and a couple of options.

[agentcore-cli-automation]

The hybrid approach addresses both previous concerns cleanly:

• The search API handles the general case efficiently regardless of repo size, solving the >100 issues/PRs pagination problem from the first review.
• The listForRepo fallback sorted by created desc with per_page: 30 covers the search-indexing-delay race window from the second review — a freshly-created issue will be at the top of the recently-created list, well within 30 items even accounting for concurrent PR activity.

The exact-title check i.title === title on both paths correctly compensates for the substring behavior of search's in:title and also makes the fallback robust against PRs with similar titles (since listForRepo returns both issues and PRs).

workflowName is validated against /^[A-Za-z0-9 _()\-]+$/ before being interpolated into the search query, so no injection concern.

LGTM.

[Hweinstock]

Description

The dedup logic in ci-failure-issue.yml filtered by labels (high-severity,ci) when checking for existing issues via listForRepo. If the token creating the issue does not have permission to apply labels, the issue is created without labels. On subsequent runs, the dedup query cannot find it (because it filters on labels that were never applied), causing duplicate issues.

This PR removes the labels parameter from the listForRepo call so dedup relies solely on title matching.

Related Issue

N/A — discovered during CI workflow re-runs.

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

Re-run the CI failure workflow and verify it does not create a duplicate issue when one already exists (regardless of whether labels were applied).

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

No source code changes — workflow-only fix. No unit/integ tests apply.

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[agentcore-cli-automation]

Thanks for the fix — the root cause analysis is correct. I have one concern about the new dedup query that I think should be addressed before merging.

The repo currently has ~85 open issues and ~44 open PRs (≈129 total). Since listForRepo returns issues and PRs (PRs count as issues in this endpoint) and this call fetches only the first page with per_page: 100, the CI failure issue being deduped against will fall off the page as soon as there are >100 newer open issues/PRs. The previous labels: 'high-severity,ci' filter kept the result set small enough that a single page was always sufficient; removing it makes the existing single-page limitation a real correctness problem right now, not a theoretical one.

See the inline comment for options.

[agentcore-cli-automation]

The switch to the search API addresses the >100-issues pagination concern from my previous review — thanks for iterating on this.

I have one remaining concern: the GitHub search API has a well-known indexing delay (typically seconds to a minute or more) between when an issue is created and when it becomes findable via search. This reintroduces a duplicate-issue risk that the previous listForRepo approach did not have, because listForRepo reads from the primary datastore and reflects newly-created issues immediately.

See inline comment for details and a couple of options.

[agentcore-cli-automation]

The hybrid approach addresses both previous concerns cleanly:

• The search API handles the general case efficiently regardless of repo size, solving the >100 issues/PRs pagination problem from the first review.
• The listForRepo fallback sorted by created desc with per_page: 30 covers the search-indexing-delay race window from the second review — a freshly-created issue will be at the top of the recently-created list, well within 30 items even accounting for concurrent PR activity.

The exact-title check i.title === title on both paths correctly compensates for the substring behavior of search's in:title and also makes the fallback robust against PRs with similar titles (since listForRepo returns both issues and PRs).

workflowName is validated against /^[A-Za-z0-9 _()\-]+$/ before being interpolated into the search query, so no injection concern.

LGTM.

[Hweinstock]

Description

The dedup logic in ci-failure-issue.yml filtered by labels (high-severity,ci) when checking for existing issues via listForRepo. If the token creating the issue does not have permission to apply labels, the issue is created without labels. On subsequent runs, the dedup query cannot find it (because it filters on labels that were never applied), causing duplicate issues.

This PR removes the labels parameter from the listForRepo call so dedup relies solely on title matching.

Related Issue

N/A — discovered during CI workflow re-runs.

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

Re-run the CI failure workflow and verify it does not create a duplicate issue when one already exists (regardless of whether labels were applied).

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

No source code changes — workflow-only fix. No unit/integ tests apply.

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[agentcore-cli-automation]

Thanks for the fix — the root cause analysis is correct. I have one concern about the new dedup query that I think should be addressed before merging.

The repo currently has ~85 open issues and ~44 open PRs (≈129 total). Since listForRepo returns issues and PRs (PRs count as issues in this endpoint) and this call fetches only the first page with per_page: 100, the CI failure issue being deduped against will fall off the page as soon as there are >100 newer open issues/PRs. The previous labels: 'high-severity,ci' filter kept the result set small enough that a single page was always sufficient; removing it makes the existing single-page limitation a real correctness problem right now, not a theoretical one.

See the inline comment for options.

[agentcore-cli-automation]

The switch to the search API addresses the >100-issues pagination concern from my previous review — thanks for iterating on this.

I have one remaining concern: the GitHub search API has a well-known indexing delay (typically seconds to a minute or more) between when an issue is created and when it becomes findable via search. This reintroduces a duplicate-issue risk that the previous listForRepo approach did not have, because listForRepo reads from the primary datastore and reflects newly-created issues immediately.

See inline comment for details and a couple of options.

[agentcore-cli-automation]

The hybrid approach addresses both previous concerns cleanly:

• The search API handles the general case efficiently regardless of repo size, solving the >100 issues/PRs pagination problem from the first review.
• The listForRepo fallback sorted by created desc with per_page: 30 covers the search-indexing-delay race window from the second review — a freshly-created issue will be at the top of the recently-created list, well within 30 items even accounting for concurrent PR activity.

The exact-title check i.title === title on both paths correctly compensates for the substring behavior of search's in:title and also makes the fallback robust against PRs with similar titles (since listForRepo returns both issues and PRs).

workflowName is validated against /^[A-Za-z0-9 _()\-]+$/ before being interpolated into the search query, so no injection concern.

LGTM.

[Hweinstock]

Description

The dedup logic in ci-failure-issue.yml filtered by labels (high-severity,ci) when checking for existing issues via listForRepo. If the token creating the issue does not have permission to apply labels, the issue is created without labels. On subsequent runs, the dedup query cannot find it (because it filters on labels that were never applied), causing duplicate issues.

This PR removes the labels parameter from the listForRepo call so dedup relies solely on title matching.

Related Issue

N/A — discovered during CI workflow re-runs.

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

Re-run the CI failure workflow and verify it does not create a duplicate issue when one already exists (regardless of whether labels were applied).

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

No source code changes — workflow-only fix. No unit/integ tests apply.

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[agentcore-cli-automation]

Thanks for the fix — the root cause analysis is correct. I have one concern about the new dedup query that I think should be addressed before merging.

The repo currently has ~85 open issues and ~44 open PRs (≈129 total). Since listForRepo returns issues and PRs (PRs count as issues in this endpoint) and this call fetches only the first page with per_page: 100, the CI failure issue being deduped against will fall off the page as soon as there are >100 newer open issues/PRs. The previous labels: 'high-severity,ci' filter kept the result set small enough that a single page was always sufficient; removing it makes the existing single-page limitation a real correctness problem right now, not a theoretical one.

See the inline comment for options.

[agentcore-cli-automation]

The switch to the search API addresses the >100-issues pagination concern from my previous review — thanks for iterating on this.

I have one remaining concern: the GitHub search API has a well-known indexing delay (typically seconds to a minute or more) between when an issue is created and when it becomes findable via search. This reintroduces a duplicate-issue risk that the previous listForRepo approach did not have, because listForRepo reads from the primary datastore and reflects newly-created issues immediately.

See inline comment for details and a couple of options.

[agentcore-cli-automation]

The hybrid approach addresses both previous concerns cleanly:

• The search API handles the general case efficiently regardless of repo size, solving the >100 issues/PRs pagination problem from the first review.
• The listForRepo fallback sorted by created desc with per_page: 30 covers the search-indexing-delay race window from the second review — a freshly-created issue will be at the top of the recently-created list, well within 30 items even accounting for concurrent PR activity.

The exact-title check i.title === title on both paths correctly compensates for the substring behavior of search's in:title and also makes the fallback robust against PRs with similar titles (since listForRepo returns both issues and PRs).

workflowName is validated against /^[A-Za-z0-9 _()\-]+$/ before being interpolated into the search query, so no injection concern.

LGTM.

[Hweinstock]

Description

The dedup logic in ci-failure-issue.yml filtered by labels (high-severity,ci) when checking for existing issues via listForRepo. If the token creating the issue does not have permission to apply labels, the issue is created without labels. On subsequent runs, the dedup query cannot find it (because it filters on labels that were never applied), causing duplicate issues.

This PR removes the labels parameter from the listForRepo call so dedup relies solely on title matching.

Related Issue

N/A — discovered during CI workflow re-runs.

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

Re-run the CI failure workflow and verify it does not create a duplicate issue when one already exists (regardless of whether labels were applied).

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

No source code changes — workflow-only fix. No unit/integ tests apply.

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[agentcore-cli-automation]

Thanks for the fix — the root cause analysis is correct. I have one concern about the new dedup query that I think should be addressed before merging.

The repo currently has ~85 open issues and ~44 open PRs (≈129 total). Since listForRepo returns issues and PRs (PRs count as issues in this endpoint) and this call fetches only the first page with per_page: 100, the CI failure issue being deduped against will fall off the page as soon as there are >100 newer open issues/PRs. The previous labels: 'high-severity,ci' filter kept the result set small enough that a single page was always sufficient; removing it makes the existing single-page limitation a real correctness problem right now, not a theoretical one.

See the inline comment for options.

[agentcore-cli-automation]

The switch to the search API addresses the >100-issues pagination concern from my previous review — thanks for iterating on this.

I have one remaining concern: the GitHub search API has a well-known indexing delay (typically seconds to a minute or more) between when an issue is created and when it becomes findable via search. This reintroduces a duplicate-issue risk that the previous listForRepo approach did not have, because listForRepo reads from the primary datastore and reflects newly-created issues immediately.

See inline comment for details and a couple of options.

[agentcore-cli-automation]

The hybrid approach addresses both previous concerns cleanly:

• The search API handles the general case efficiently regardless of repo size, solving the >100 issues/PRs pagination problem from the first review.
• The listForRepo fallback sorted by created desc with per_page: 30 covers the search-indexing-delay race window from the second review — a freshly-created issue will be at the top of the recently-created list, well within 30 items even accounting for concurrent PR activity.

The exact-title check i.title === title on both paths correctly compensates for the substring behavior of search's in:title and also makes the fallback robust against PRs with similar titles (since listForRepo returns both issues and PRs).

workflowName is validated against /^[A-Za-z0-9 _()\-]+$/ before being interpolated into the search query, so no injection concern.

LGTM.

[Hweinstock]

Description

The dedup logic in ci-failure-issue.yml filtered by labels (high-severity,ci) when checking for existing issues via listForRepo. If the token creating the issue does not have permission to apply labels, the issue is created without labels. On subsequent runs, the dedup query cannot find it (because it filters on labels that were never applied), causing duplicate issues.

This PR removes the labels parameter from the listForRepo call so dedup relies solely on title matching.

Related Issue

N/A — discovered during CI workflow re-runs.

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

Re-run the CI failure workflow and verify it does not create a duplicate issue when one already exists (regardless of whether labels were applied).

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

No source code changes — workflow-only fix. No unit/integ tests apply.

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[agentcore-cli-automation]

Thanks for the fix — the root cause analysis is correct. I have one concern about the new dedup query that I think should be addressed before merging.

The repo currently has ~85 open issues and ~44 open PRs (≈129 total). Since listForRepo returns issues and PRs (PRs count as issues in this endpoint) and this call fetches only the first page with per_page: 100, the CI failure issue being deduped against will fall off the page as soon as there are >100 newer open issues/PRs. The previous labels: 'high-severity,ci' filter kept the result set small enough that a single page was always sufficient; removing it makes the existing single-page limitation a real correctness problem right now, not a theoretical one.

See the inline comment for options.

[agentcore-cli-automation]

The switch to the search API addresses the >100-issues pagination concern from my previous review — thanks for iterating on this.

I have one remaining concern: the GitHub search API has a well-known indexing delay (typically seconds to a minute or more) between when an issue is created and when it becomes findable via search. This reintroduces a duplicate-issue risk that the previous listForRepo approach did not have, because listForRepo reads from the primary datastore and reflects newly-created issues immediately.

See inline comment for details and a couple of options.

[agentcore-cli-automation]

The hybrid approach addresses both previous concerns cleanly:

• The search API handles the general case efficiently regardless of repo size, solving the >100 issues/PRs pagination problem from the first review.
• The listForRepo fallback sorted by created desc with per_page: 30 covers the search-indexing-delay race window from the second review — a freshly-created issue will be at the top of the recently-created list, well within 30 items even accounting for concurrent PR activity.

The exact-title check i.title === title on both paths correctly compensates for the substring behavior of search's in:title and also makes the fallback robust against PRs with similar titles (since listForRepo returns both issues and PRs).

workflowName is validated against /^[A-Za-z0-9 _()\-]+$/ before being interpolated into the search query, so no injection concern.

LGTM.

[Hweinstock]

Description

The dedup logic in ci-failure-issue.yml filtered by labels (high-severity,ci) when checking for existing issues via listForRepo. If the token creating the issue does not have permission to apply labels, the issue is created without labels. On subsequent runs, the dedup query cannot find it (because it filters on labels that were never applied), causing duplicate issues.

This PR removes the labels parameter from the listForRepo call so dedup relies solely on title matching.

Related Issue

N/A — discovered during CI workflow re-runs.

Documentation PR

N/A

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

Re-run the CI failure workflow and verify it does not create a duplicate issue when one already exists (regardless of whether labels were applied).

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

No source code changes — workflow-only fix. No unit/integ tests apply.

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[agentcore-cli-automation]

Thanks for the fix — the root cause analysis is correct. I have one concern about the new dedup query that I think should be addressed before merging.

The repo currently has ~85 open issues and ~44 open PRs (≈129 total). Since listForRepo returns issues and PRs (PRs count as issues in this endpoint) and this call fetches only the first page with per_page: 100, the CI failure issue being deduped against will fall off the page as soon as there are >100 newer open issues/PRs. The previous labels: 'high-severity,ci' filter kept the result set small enough that a single page was always sufficient; removing it makes the existing single-page limitation a real correctness problem right now, not a theoretical one.

See the inline comment for options.

[agentcore-cli-automation]

The switch to the search API addresses the >100-issues pagination concern from my previous review — thanks for iterating on this.

I have one remaining concern: the GitHub search API has a well-known indexing delay (typically seconds to a minute or more) between when an issue is created and when it becomes findable via search. This reintroduces a duplicate-issue risk that the previous listForRepo approach did not have, because listForRepo reads from the primary datastore and reflects newly-created issues immediately.

See inline comment for details and a couple of options.

[agentcore-cli-automation]

The hybrid approach addresses both previous concerns cleanly:

• The search API handles the general case efficiently regardless of repo size, solving the >100 issues/PRs pagination problem from the first review.
• The listForRepo fallback sorted by created desc with per_page: 30 covers the search-indexing-delay race window from the second review — a freshly-created issue will be at the top of the recently-created list, well within 30 items even accounting for concurrent PR activity.

The exact-title check i.title === title on both paths correctly compensates for the substring behavior of search's in:title and also makes the fallback robust against PRs with similar titles (since listForRepo returns both issues and PRs).

workflowName is validated against /^[A-Za-z0-9 _()\-]+$/ before being interpolated into the search query, so no injection concern.

LGTM.