Key the directory toggle on the website group, not the generation - #111
Merged
Merged
Conversation
The listing switch never appeared on any finished website, and the
stable-link upgrade silently never fired. Same root cause, and it was
mine.
ai_generations.id is the SERVER's jobId, returned from POST /generate.
WebsiteGeneration.id is a CLIENT-side uuid - a different value - and the
client discards the jobId once the job completes (_clearPendingJob), so
it is not even available later.
The status poll correctly used jobId, but the two calls I added for the
directory used generation.id:
- fetchListingState -> GET /status/<client-uuid> -> 404 -> null ->
_DirectoryListingSwitch hid itself, so the toggle was unreachable.
- setDirectoryListing -> POST /generations/<client-uuid>/listing -> 404,
so listing_url stayed NULL and the directory kept showing the raw
per-generation gateway URL.
Both now address the website GROUP (tag id) via the new group-scoped
endpoints. The group is stable, is always known here, and is already what
the directory de-duplicates on - so it also matches the product model of
one directory entry per website rather than per generation.
_listedOnServer is likewise re-keyed by group.
Server half: functionland/pinning-service.
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.
The directory toggle was never visible on a finished website, and the fxfiles.top link upgrade never reached the server. Both are the same bug.
ai_generations.idis the SERVER's jobId, returned by POST /generate.WebsiteGeneration.idis a client-side uuid. They are different values - and the client discards the jobId once a job completes, so it is not recoverable later either.The status poll used jobId correctly. The two calls I added for the directory used
generation.id, so:fetchListingStatehit/status/<client-uuid>-> 404 -> returned null -> the switch hid ITSELF. No toggle ever rendered.listing_urlpush 404'd silently, which is why the directory kept showing the raw ipfs.cloud.fx.land/gateway URL instead of the stable fxfiles.top/w/<k51...> front door.Now keyed on the website GROUP (tagId), against the new group-scoped endpoints (pinning-service#87):
The group is stable across regenerations, always known to the client, and is already what the directory de-duplicates on - so one website is one entry regardless of how many times it was regenerated, and flipping the toggle later updates that same entry.
_listedOnServeris re-keyed by group to match.Needs the AI service deployed for the endpoints to exist; until then the toggle stays hidden rather than showing a control that cannot save.
v1.11.16.0. CI green: analyze clean, 971 passed / 25 skipped.