What causes "No job with id {id} known" in invoke-ai/InvokeAI?

Verify the id came from a job returned by this same service instance in this process (e.g. from install() or get_job_by_source()).

invoke-ai/InvokeAI · error · ValueError

No job with id {id} known

Error message

No job with id {id} known

What it means

ModelInstallService.get_job_by_id() looks up an install job by its integer id in the in-memory list of jobs. It throws ValueError when no job in the service's registry matches the given id, meaning the job was never started in this process or the registry entry is gone (e.g. after a restart, since jobs are not persisted).

Source

Thrown at invokeai/app/services/model_install/model_install_default.py:561

                self._install_condition.notify_all()
            raise

        with self._install_condition:
            self._install_jobs.append(install_job)
            self._pending_sources.remove(source_key)
            self._install_condition.notify_all()
        return install_job

    def list_jobs(self) -> List[ModelInstallJob]:  # noqa D102
        return self._install_jobs

    def get_job_by_source(self, source: ModelSource) -> List[ModelInstallJob]:  # noqa D102
        return [x for x in self._install_jobs if x.source == source]

    def get_job_by_id(self, id: int) -> ModelInstallJob:  # noqa D102
        jobs = [x for x in self._install_jobs if x.id == id]
        if not jobs:
            raise ValueError(f"No job with id {id} known")
        assert len(jobs) == 1
        assert isinstance(jobs[0], ModelInstallJob)
        return jobs[0]

    def wait_for_job(self, job: ModelInstallJob, timeout: int = 0) -> ModelInstallJob:
        """Block until the indicated job has reached terminal state, or when timeout limit reached."""
        start = time.time()
        while not job.in_terminal_state:
            if self._install_completed_event.wait(timeout=5):  # in case we miss an event
                self._install_completed_event.clear()
            if timeout > 0 and time.time() - start > timeout:
                raise TimeoutError("Timeout exceeded")
        return job

    def wait_for_installs(self, timeout: int = 0) -> List[ModelInstallJob]:  # noqa D102
        """Block until all installation jobs are done."""
        start = time.time()
        restore_timeout = timeout if timeout > 0 else None

View on GitHub (pinned to 0b6a024f2f)

Solutions

Verify the id came from a job returned by this same service instance in this process (e.g. from install() or get_job_by_source()).
List current jobs (e.g. via the jobs list/GET /install endpoints) and use a valid id.
After a service restart, re-list jobs instead of reusing persisted ids; if persistence is needed, store source info and re-lookup by source.
Ensure the id is an int, matching the x.id type stored on the job.

Example fix

// before
job = service.get_job_by_id(42)  # id from a previous session
// after
jobs = service.get_job_by_source(HFModelSource(repo_id='author/model'))
if not jobs:
    raise RuntimeError('Job not found; service may have restarted')
job = jobs[0]

Defensive patterns

Strategy: try-catch

Validate before calling

ids = {j.id for j in service.get_jobs()} if hasattr(service, 'get_jobs') else None
# or track ids returned by install():
valid_id = isinstance(job_id, int) and job_id in tracked_ids

Type guard

def job_exists(service, job_id: int) -> bool:
    try:
        service.get_job_by_id(job_id)
        return True
    except ValueError:
        return False

Try / catch

try:
    job = service.get_job_by_id(job_id)
except ValueError:
    job = None  # job unknown: service restarted or bad id; re-list or re-install

Prevention

Never persist and reuse job ids across service restarts; re-list jobs instead.
Capture ids only from values returned by install()/list endpoints of the same instance.
Always pass int ids, not strings.
On 'unknown', fall back to get_job_by_source() with the original source.

When it happens

Trigger: Calling get_job_by_id() with an id that was never created; using an id from a previous service run/restart (jobs live only in memory); passing a job id from a different service instance; integer/string mixups (id stored as string).

Common situations: API client resumes after server restart and reuses a stale job id; a UI polls a job that was cancelled and purged; tests construct jobs directly without registering them via the service.

Related errors

AI-assisted analysis of invoke-ai/InvokeAI@0b6a024f2f (2026-08-29). Data as JSON: /api/errors/ab432ade783bb4ed. Report an issue: GitHub.