Stacklok docs team / @reyortiz3 — here is a ready-to-adapt subsection for the separate Fetch documentation follow-up in stacklok/toolhive#6475 . This addresses configuration-state confusion; it does not claim the customer's registry-related symptom remains an unresolved runtime defect.
Before changing an existing Fetch workload
First inspect the local state:
thv list --all
thv config get-registry
Do not paste registry URLs containing credentials into a public issue. A stopped workload can still reserve the name fetch. If fetch exists and you want its saved configuration, thv start fetch resumes that configuration; start/restart do not apply new run-only flags. If fetch is already running with the desired configuration, no recreation is needed.
If you need different run-only settings, first record the intended configuration and assess interruption/consumer impact. Removing and recreating the workload requires the operator's decision: thv rm fetch removes the existing workload, then a reviewed thv run command creates it with the new configuration. Do not copy a gateway-access flag merely to work around a registry or permission error.
If fetch is absent yet lookup fails, inspect whether the configured registry is the intended one before changing permissions or registry settings. Do not automatically unset a custom registry.
A useful docs check has four rows: stopped+same config => resume; running+same config => no replacement; existing+changed config => operator-approved recreate; absent+lookup failure => inspect registry first. These are proposed instructions, not a transcript from an executed CLI session. The current command source and Fetch guide were reviewed; no workload or registry was changed. AI-assisted documentation suggestion, reviewed before sharing.
Stacklok docs team / @reyortiz3 — here is a ready-to-adapt subsection for the separate Fetch documentation follow-up in stacklok/toolhive#6475 . This addresses configuration-state confusion; it does not claim the customer's registry-related symptom remains an unresolved runtime defect.
Before changing an existing Fetch workload
First inspect the local state:
Do not paste registry URLs containing credentials into a public issue. A stopped workload can still reserve the name fetch. If fetch exists and you want its saved configuration, thv start fetch resumes that configuration; start/restart do not apply new run-only flags. If fetch is already running with the desired configuration, no recreation is needed.
If you need different run-only settings, first record the intended configuration and assess interruption/consumer impact. Removing and recreating the workload requires the operator's decision: thv rm fetch removes the existing workload, then a reviewed thv run command creates it with the new configuration. Do not copy a gateway-access flag merely to work around a registry or permission error.
If fetch is absent yet lookup fails, inspect whether the configured registry is the intended one before changing permissions or registry settings. Do not automatically unset a custom registry.
A useful docs check has four rows: stopped+same config => resume; running+same config => no replacement; existing+changed config => operator-approved recreate; absent+lookup failure => inspect registry first. These are proposed instructions, not a transcript from an executed CLI session. The current command source and Fetch guide were reviewed; no workload or registry was changed. AI-assisted documentation suggestion, reviewed before sharing.