[NoxzRCW]

Summary

POST /api/playground/simulate-route returned HTTP 500 for every persisted combo, which made the Combo Playground page unusable. Every "Simulate Route" click failed, whichever combo was selected:

{"error":"Simulation error: Cannot read properties of undefined (reading 'length')"}

This is not the "combo not found" path. A bogus comboId correctly returns 404, so the combo is found and then the handler crashes while iterating its targets.

The route read combo.targets, but getCombos() returns records normalized by normalizeComboRecord(), which is schema version 2 and keeps its steps under models as a ComboStep[]. There is no targets property, so comboInfo.targets was always undefined and the loop below dereferenced undefined.length. The inline body.combo branch worked only because the caller supplies targets explicitly per simulateRequestSchema, which is why the dashboard was the only broken path.

There is a second mismatch in the same loop. A step's provider comes from step.providerId, or from the provider/model prefix of step.model, never from a top-level step.provider. So even with targets populated, the connection lookup would have failed to resolve and produced spurious Provider undefined not configured warnings. Both are handled here.

combo-ref and provider-wildcard steps are not expanded by the simulator. Rather than dropping them silently they now surface as warnings, and the wildcard is listed unresolved so the operator can see it is in the route.

Related Issues

• Closes fix(playground): simulate-route 500s for every persisted combo — reads combo.targets but getCombos() returns models #11822

Validation

• Change type: routing
• Focused tests and category gates from the golden path
• npm run lint
• Reconciled with the current active release base; focused checks rerun afterward
• Production-code changes include a new or updated automated test in this PR

node --import tsx/esm --test tests/unit/playground-simulate-route-combo-steps-11822.test.ts
# tests 6 / pass 6 / fail 0

npm run typecheck:core   # 0 errors
npm run lint             # clean

Tests Added Or Updated

• tests/unit/playground-simulate-route-combo-steps-11822.test.ts (new)

Covers the three step kinds, providerId winning over the model prefix, a serialized models column, and the malformed inputs (null, unparseable JSON, junk entries) that should degrade to an empty target list rather than throw.

Coverage Notes

The mapping lives in src/lib/combos/simulatorTargets.ts and is fully covered by the new test file. The route itself keeps its existing shape and just calls into it.

Reviewer Notes

I put the mapping in src/lib/combos/ rather than inline in the route, for two reasons. A Next.js App Router route module cannot export anything besides its handlers and the documented route config, so the helper would not have been testable where the issue suggested putting it. And ComboStep already lives under src/lib/combos/, so the mapping sits next to the type it consumes.

Routing itself was never affected. Real requests through these combos always dispatched correctly, this was only the simulator's view of them.

If you would rather have combo-ref steps expanded through resolveComboTargets() instead of surfacing as a warning, say so and I will do that instead. I went with the warning because expanding nested combos in the simulator raises cycle-handling questions that felt out of scope for a 500 fix.

[diegosouzapw]

Thanks for this — and sorry for the overlap. #11862 landed first and already fixed the
core #11822 crash (reading combo.models instead of the nonexistent combo.targets,
resolving provider via providerId/model-prefix), so this conflicted by the time I got
to it.

Your one genuinely distinct contribution — surfacing combo-ref and provider-wildcard
steps with a specific warning instead of a generic "unsupported step" count, and showing
the wildcard as an unresolved target — was real value worth keeping. I hand-applied that
part onto #11862's code (full credit to your design) as #11930, since your extracted
comboStepsToTargets() helper didn't cover the plain-string step shape #11862 also
handles. Closing this one now that its distinct value has landed. Thank you for the
thorough regression coverage and the clear writeup either way!