Feature request: plugin update status + update mutation (parity with Docker container updates)

Open
#2,012 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
graphql, typescript
Domain
api, backend-api-design

Research direction

Start by tracing the existing installPlugin mutation, Plugin schema, PluginInstallOperation, and Docker update-status and update mutation patterns. Review how the webgui re-runs a plugin's .plg URL, then determine the needed schema and resolver entry points. Done means clients can read plugin update status and invoke individual or all-plugin updates with operation tracking comparable to Docker.

Written by the indexing model from the issue text.

Description

Context

Third-party clients (mobile/desktop dashboards, monitoring tools) currently can't tell users when an installed Unraid plugin has a newer .plg version available. The only programmatic install path today is installPlugin(input: InstallPluginInput!): PluginInstallOperation!, which requires the caller to already know the URL of a newer release.

Current schema
type Plugin {
    name: String!
    version: String!
    hasApiModule: Boolean
    hasCliModule: Boolean
}

No latestVersion, no updateAvailable, no equivalent of the Docker update-status surface.

Existing pattern that works well — Docker

The Docker side already solves this cleanly:

enum UpdateStatus { UP_TO_DATE  UPDATE_AVAILABLE  REBUILD_READY  UNKNOWN }
type ExplicitStatusItem { name: String!  updateStatus: UpdateStatus! }
type Docker { containerUpdateStatuses: [ExplicitStatusItem!]! }
type DockerMutations {
    updateContainer(id: PrefixedID!): DockerContainer!
    updateAllContainers: [DockerContainer!]!
}

Clients can render a "X updates available" badge and a one-tap update action without scraping registries.

Proposal — mirror for plugins

Either extend Plugin directly:

type Plugin {
    # … existing fields
    latestVersion: String
    updateStatus: UpdateStatus
}

…or add a parallel query field analogous to containerUpdateStatuses:

type Query {
    pluginUpdateStatuses: [ExplicitStatusItem!]!
}

Plus a mutation, reusing the existing PluginInstallOperation tracking:

type UnraidPluginsMutations {
    updatePlugin(name: String!): PluginInstallOperation!
    updateAllPlugins: [PluginInstallOperation!]!
}
Why this matters

Plugin updates today require users to visit Community Applications or each plugin's source URL manually. A schema-level surface unlocks "managed-from-anywhere" parity with the Docker experience the API already provides — and the implementation can reuse the existing .plg re-install path (Unraid's webgui already updates by re-running the .plg from the URL it has).

Dominant language
TypeScript
Stars
113
Forks
22
Avg merge
10h 40m
Merged PRs (30d)
13

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from unraid/api

All issues in unraid/api

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.