Skip to content

Mapper: show orphan-algorithm candidates in the by-algorithm view#38

Open
paynejd wants to merge 1 commit into
mainfrom
issues#2556-orphan-algo-by-algorithm-view
Open

Mapper: show orphan-algorithm candidates in the by-algorithm view#38
paynejd wants to merge 1 commit into
mainfrom
issues#2556-orphan-algo-by-algorithm-view

Conversation

@paynejd
Copy link
Copy Markdown
Member

@paynejd paynejd commented Jun 2, 2026

closes OpenConceptLab/ocl_issues#2556

Problem

In the by-algorithm grouping of the Candidates tab, getCandidates() iterates only the project's configured algorithms (algosSelected). A candidate's algorithm_id can legitimately fall outside that set — the project was reconfigured after running algorithms, or the PR3-C v1→v2 migration (oclmap#37 / ocl_issues#2555) saved a tag that doesn't match a configured algo id. Those "orphan-algo" candidates appeared in no bucket in the by-algorithm view, even though they already render in:

  • the default quality (by-concept) view, and
  • the AI Assistant payload

— both gated by target-repo membership (conceptBelongsToTargetRepo), never by algorithm_id.

Change

  • viewBuilders.js: add pure, unit-tested helper getOrphanAlgorithmIds(rowState, configuredIds) → the distinct candidate algorithm_ids not in the configured set (first-seen order, null ids ignored).
  • Candidates.jsx (getCandidates() algorithm branch): after the sorted configured algos, append one bucket per orphan id, built with the existing buildAlgorithmRowViews. Each uses a synthesized algo of {id, name: t('map_project.unrecognized_algorithm'), order: Infinity} → header renders as Unrecognized algorithm (<id>). The render path only reads algo.name/algo.id/algo.type?.…, so the minimal synthesized object is safe.
  • Orphan buckets keep the by-algo full mix (no target-repo filter); per-row mappability stays gated downstream by isTargetRepoView / conceptBelongsToTargetRepo, exactly as for configured algos.
  • i18n key unrecognized_algorithm added to en/es/zh.

The existing hasCandidates-desc / algo.order-asc ordering of configured algos is unchanged; orphans are concatenated strictly after all configured buckets.

Tests

  • 5 new unit tests in __tests__/views.test.js covering getOrphanAlgorithmIds (null rowState, distinct/deduped orphans, all-configured → [], null algorithm_id ignored, round-trip into buildAlgorithmRowViews).
  • npm test → 141 pass / 0 fail. npm run eslint → clean. webpack dev build compiles successfully.

Out of scope

The migration itself (oclmap#37) and the quality view / AI payload (already surface these candidates).

🤖 Generated with Claude Code

…by-algorithm view

The by-algorithm grouping of the Candidates tab only iterated the
project's configured algorithms[], so candidates whose algorithm_id is
not in algosSelected (project reconfigured after running algorithms, or
PR3-C v1->v2 migration tags) appeared in no bucket — even though they
already render in the quality view and the AI payload, both gated by
target-repo membership rather than algorithm_id.

Add getOrphanAlgorithmIds(rowState, configuredIds) to viewBuilders (pure,
unit-tested) and, in getCandidates()'s algorithm branch, append one bucket
per orphan id after the configured algos using the existing
buildAlgorithmRowViews. Buckets use a synthesized algo {id, name, order:
Infinity} labeled 'Unrecognized algorithm (<id>)' and keep the by-algo
full mix (no target-repo filter; per-row mappability stays gated
downstream).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Mapper: show orphan-algorithm candidates in the by-algorithm Candidates view

1 participant