Updating DSH Plugin Hub: cache, version and rollback

A routine update finished cleanly, the version number changed, and the plugin market still looked exactly as it had before. That is the moment to ask a narrower question about your DeepSeek Harness setup: which version line did you actually move? The answer decides whether you are dealing with a cache, a restart, or a rollback.

The DSH plugin update that changes nothing visible

An update that produces no visible change is usually evidence of a version-line mistake, not a broken release.

On a normal evening you click update, watch the spinner, and get a confirmation. The version string in the details panel may even change. Then the market opens with the same layout, the same categories and the same installed list, and the instinct is to assume the release did nothing. That instinct skips a step: an update only changes the layer that received it, and each layer in a DeepSeek Harness installation owns a different part of the interface.

The core owns runtime behavior. The Hub owns the market view. Ordinary DSH plugins own their own panels and commands. When the market looks stale, the most likely explanation is that the core moved while the Hub stayed put, or the reverse. Neither case says anything about the quality of the release. It says the wrong layer was compared against the expectation.

A second common scene: the Hub updated, the version is new, and the page is blank or half-rendered. That is a different failure with a different cause, and treating it as "the update did nothing" sends you toward reinstalling when a refresh would have been enough. The first move is always to name the layer, then name the symptom.

Keep a short record of the three versions before touching anything. It takes seconds and prevents hours of guessing later. A written baseline also makes it obvious when a second update changes something you did not intend to touch.

Which DSH plugin version line did you actually update?

The core, the Hub and individual DSH plugins ship on separate tracks, and each track has its own command and its own release notes.

The DeepSeek Harness core is installed through npx, a global npm package, or a source checkout. The Hub is a plugin, installed and updated through the plugin system. A workflow plugin or a theme is a third kind of package with its own version history. These three tracks can be weeks apart, and that is normal.

Ask what you ran. If the command was a core upgrade, the Hub version did not change, no matter how many times the page reloads. If you updated the Hub from the installed list, the core binary is untouched. If you updated a single DSH plugin, only that plugin's files moved.

The question is not pedantic; it determines the next diagnostic step. A core update that leaves the market old is expected behavior. A Hub update that leaves the market old is a cache or asset problem. A plugin update that leaves its own panel old is a loading problem.

Write the versions down as a single line: core, Hub, and the plugin you meant to change, with the entry from DSH Plugin Hub open beside you. If you cannot fill in all three, you do not yet know what moved. That sentence is also the first thing to paste into a bug report.

Why a DSH plugin cache survives an update

Frontend assets and package caches can outlive the install that replaced them, which makes a successful update look inert.

The market is a web surface running inside the client. Its JavaScript, styles and index data may be cached by the client, by the embedded browser, or by the package manager that fetched the previous release. Replacing files on disk does not always invalidate those copies.

A refresh is the cheapest test. It re-renders the surface and often picks up new assets. A restart goes further: it reloads the plugin host and forces the client to rebuild its view of installed plugins. Clearing a cache is the last step, because it destroys the evidence you may need if the problem turns out to be something else.

Cache problems have a signature. The page may show an old version number beside a new one, or a category that no longer exists in the new index. Console errors about missing chunks or stale manifest hashes point the same way. None of these mean the package is broken.

If a refresh fixes it, record that. A recurring cache issue is worth a note in your upgrade log, because it will return with the next release and you will want to recognize it faster. The note should include the version pair and the step that cleared it.

Restarting the DeepSeek Harness plugin host without guessing

A restart is not a superstition; it is the step that forces the plugin host to re-read what is on disk.

The plugin host loads manifests at startup and keeps state about which plugins are active. An install performed while the host is running can leave that state pointing at an old path. Closing the client and starting it again gives the host a clean read.

Do the restart after the install finishes, not during it. Interrupting a plugin update can leave a partially written directory, which looks like a corrupt package and is much harder to diagnose than a stale cache. Wait for the confirmation, then close.

After restart, check the order of evidence: does the plugin appear in the installed list, does its version match the package you installed, and does its UI render? If the first answer is no, the problem is installation. If the first is yes and the second is no, the problem is version resolution. If both are yes and the third is no, the problem is rendering.

Only after those three checks should you consider reinstalling. Reinstalling first throws away the information the restart just gave you, and it rarely fixes a problem that a clean reload could not. A reinstall is a last resort, not a first response.

Rolling back a DSH plugin when the new version misbehaves

Rollback only works while the previous version still resolves, so confirm that before you need it.

A rollback is a reinstall of a known version, not a magic undo. The old package must still exist in the registry or in your local cache, and its configuration must still be readable by the current core. If either condition fails, rollback becomes a migration.

Keep the failing version number and the symptom together. "Market blank after 1.4.2" is useful; "update broke it" is not. The pair tells the next person which release to avoid and which behavior to test.

1. Record the failing version and the exact symptom.
2. Confirm the previous version still resolves in the registry or cache.
3. Reinstall that exact version; do not use a floating tag.
4. Restart the client so the plugin host re-reads manifests.
5. Refresh the market and re-check presence, version and rendering.
6. Compare the old behavior with the failure before closing the incident.
7. Write the result and a review date into the upgrade log.

Reinstall the previous version explicitly rather than relying on a range or a latest tag. Then restart and verify the same three surfaces you checked after the upgrade: presence, version and rendering. If the old version fails the same way, the update was not the cause.

Set a review point rather than pinning forever. A pinned version accumulates security and compatibility debt, and the next upgrade gets harder the longer you wait. Put the review point in the same log as the version.

A DSH plugin update habit that answers the question early

The fastest way out of an "update did nothing" moment is to make the three version lines visible before the update starts.

Keep a small file or note with the core version, Hub version and the plugins you rely on. Update it after every change. When something looks stale, compare the note with what the UI reports. The mismatch names the layer for you.

Update one layer at a time. When the core, the Hub and a plugin all move in the same session, any failure becomes unattributable. Sequential changes cost a few extra restarts and save entire evenings.

Treat the market as a UI with its own release cadence, not as a window into the core. That mental model alone prevents most of the confusion this article started with. A blank page is a rendering question first, a package question second, and a data-loss question almost never.

End the incident with a sentence you can reuse: which line moved, what the symptom was, and which step fixed it. That sentence is the actual output of the update, and it is worth more than the version number that started the conversation. Keep it where the next update will find it.