Skip to content

fix(tasks): fall back to active provider when task default has no model#89

Open
prime-axiom wants to merge 1 commit into
meteyou:mainfrom
prime-axiom:fix/task-default-provider-model
Open

fix(tasks): fall back to active provider when task default has no model#89
prime-axiom wants to merge 1 commit into
meteyou:mainfrom
prime-axiom:fix/task-default-provider-model

Conversation

@prime-axiom

Copy link
Copy Markdown
Contributor

Problem

getTaskDefaultProvider() returned an explicitly configured task default provider even when that provider had no enabled models. Since providers can now be created without selecting a model upfront (#87, 8824e19), such a provider starts background tasks (heartbeat, cronjobs, manual defaults) with an empty model.

The configured-provider branch short-circuited with if (resolved) return resolved, so the active-provider fallback below was never reached when the configured provider had no usable model.

Change

  • Only honor an explicitly configured task provider when it can actually run a model (explicit model pin, or a non-empty enabledModels). Otherwise fall back to the active provider/model selection — matching the documented behavior ("Defaults to the currently active chat provider").
  • Extract the resolution into a pure, dependency-injected helper resolveTaskDefaultProvider() so the logic is unit-testable; getTaskDefaultProvider() is now a thin wrapper.

No behavior change for the common paths (explicit provider:model, configured provider with models, active-provider default).

Testing

  • New unit tests in runtime-composition.test.ts cover: explicit provider+model pin, configured provider with models (unchanged), configured provider with no enabled models (falls back to active), unresolvable provider, active default, no active model, and no active provider.
  • npm run lint, npm run baseline:unit (1127), npm run baseline:api (198), npm run build — all green.

The task default-provider resolution returned an explicitly configured
provider even when it had no enabled models. Since providers can now be
created without selecting a model upfront, such a provider would start
background tasks (heartbeat, cronjobs, manual defaults) with an empty
model. Only honor a configured provider when it can run a model;
otherwise fall back to the active provider/model selection.

Extract the resolution into a pure, unit-tested helper.
@prime-axiom

Copy link
Copy Markdown
Contributor Author

Self-review (cannot self-approve via GitHub). Verified against the full checklist:

  • Scope: single focused fix, no unrelated changes.
  • Correctness: configured task providers with no enabled models previously short-circuited (if (resolved) return resolved) before the active-provider fallback, starting background tasks with an empty model. Fix only honors a configured provider when it can run a model; otherwise falls back to the active provider/model. Common paths unchanged.
  • Tests: 7 new unit tests including a regression for the empty-enabledModels case (fails on the old behavior).
  • Build/lint/tests: npm run lint, npm run baseline:unit (1127 passed), npm run baseline:api (198 passed), npm run build — all green.
  • Docs: aligns code with existing documented behavior ('Defaults to the currently active chat provider'); no doc change needed.

Ready for merge from my side.

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.

1 participant