Repository navigation
fix(jobs): name the hosting by its domain, not its id - #211
Merged
Merged
Conversation
Per-hosting forms post the hosting id as their selector and spawn_job stored it verbatim as the job's subject, so job pages read "target 01a0f15b-…" and "← Back to 01a0f15b-…". - spawn_job resolves an id-shaped target to the hosting's domain before storing it; after a delete the domain is the only name left. - /jobs, /jobs/<id> and the progress fragment resolve ids on older rows at render time (one cluster listing, skipped when no row needs it). - A finished hosting_delete no longer offers a back link to a 404. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Job pages showed the hosting's UUID as the subject ("target 01a0f15b-…", "← Back to 01a0f15b-…") instead of its domain.
Why
Most per-hosting forms post the hosting id as
selector, andspawn_jobstored that verbatim as the job'starget.Changes
spawn_job: an id-shaped target (UUID) is resolved to the hosting's domain via the cluster-widelist_hostingsbeforeJobStart. Covers all ~30 call sites at once. Forhosting_deletethis matters most: once the site is gone the domain is the only name left./jobs,/jobs/<id>and/jobs/<id>/progressresolve id targets at render time. One listing per batch, and no RPC at all when no row holds an id — so the 2 s progress poll is unchanged for new jobs. Hostings deleted before this change can't be resolved and keep their id.JobView::hosting_target: a finishedhosting_deleteno longer renders the back link (it pointed at a 404). Failed/running deletes keep it.Reviewer notes
_hosting_jobs_panelalready matches a job's target against both id and domain, so storing the domain doesn't hide running jobs there./hostings/<domain>resolves the same as/hostings/<id>, so back links still work.looks_like_hosting_idshape test;hosting_targetdelete-state test.cargo test -p hyperion-web+ clippy clean. Not walked in the dev panel (stub can't delete a real hosting).🤖 Generated with Claude Code