feat(repositories): choose between publish next and publish now - #15
Merged
Merged
Conversation
The send button promoted a repository to the head of the publication queue and nothing more, so a post that has to go out now still waited for the scheduled run. It now opens a dialog with both choices: promote to the head of the queue, or publish immediately to every enabled integration through Content Maestro's new /api/message/publish. The publication status is shown inside the dialog rather than as a toast, because that is the only place the per-integration outcome fits: one row per integration, spinner while the request is in flight, then sent or failed with the error the connector reported. Progress is not faked per integration - the backend is a single synchronous call, and flipping a row to sent on a guess would be a lie about a publication. The integration list comes from the api-configs already loaded by the dashboard, so the dialog costs no extra request. Content Maestro still resolves the enabled set itself, so a run can report an integration this tab's cached list does not know about; the rows are built from both, and an expected integration with no reported outcome is shown as a failure rather than silently as a success. The send button is no longer disabled on the row that is already next: that is precisely the row most likely to need publishing now. Only the "publish next" action inside the dialog is disabled for it. A request is given a 240 s abort as a safety net, not as a cancellation - aborting does not stop the run on the server - so the timeout says the publication may still be running instead of claiming it failed. Also fixes an adjacent lie: promoteRepositoryToNext answers an unconfigured API with an error payload instead of throwing, and the handlers ignored it, so an unconfigured dashboard toasted "Repository will be published next" after doing nothing at all.
Deploying content-sentinel with
|
| Latest commit: |
5c3a96c
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://943751c1.content-sentinel.pages.dev |
| Branch Preview URL: | https://feat-publish-now.content-sentinel.pages.dev |
Review of the previous commit found four ways the dialog could mislead or trap the user. One dialog instance serves every row, and nothing stopped a row's send button from retargeting it while a publication was in flight. Repo A's request would then land on a dialog now titled with repo B, showing A's outcome as B's. The send button is now disabled while the dialog is working, the request is aborted when the dialog is retargeted, and the response is dropped unless the dialog still points at the repository it was made for. The summary banner claimed the repository "left the queue" from the success counts alone, so a run whose posted marking failed contradicted the posted_error warning printed right below it - and sent the reader to "Publish again" for a repost the scheduled run was about to do anyway. What it says about the queue now follows `posted`. Dismissal was blocked for any in-flight request, including the promotion, which carries no timeout of its own: a stalled content-alchemist left a dialog that could not be closed at all, where the confirm dialog it replaced could always be cancelled. Only a publication blocks dismissal now, because only its per-integration result exists nowhere else. An empty integration list read as "no integration is enabled" even while the configs were still loading, so opening the dialog during a cold load refused to publish for no reason. The loading flag is threaded through and says so. Also: the send button lost the "already next" wording when it stopped being disabled for that row, leaving screen readers with no way to tell that row apart - restored as part of the label. And promoting a repository the queue has since moved past returned silently, closing the dialog as if it had worked; it now says what happened.
Driving the dialog against a local Content Maestro showed every integration row saying "Sending..." with a spinner before anything had been clicked: the pending state is also the state the list is in before a publication starts. The spinner now belongs to the publishing phase only, so the pre-run list reads as what it is - where the post will go.
Member
Author
|
🎉 This PR is included in version 1.51.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
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.
Why
The send button on a repository row promoted it to the head of the publication queue and nothing more, so a post that has to go out now still waited for the scheduled run. After a bad record was deleted from the queue once it had already been published, there was no way to get a replacement post out at all.
What
The button now opens a dialog with both choices:
POST /api/message/publish(feat(api): publish a repository immediately content-maestro#3).The publication status is shown inside the dialog rather than as a toast, because that is the only place the per-integration outcome fits: one row per integration, a spinner while the request is in flight, then sent or failed with the error the connector reported, above a summary banner.
Deliberate choices
api-configsthe dashboard already loads. Content Maestro still resolves the enabled set itself, so a run can report an integration this tab's cached list does not know about (enabled in another tab) and can omit one the list still carries (disabled since). Rows are built from both, and an expected integration with no reported outcome is shown as a failure rather than silently as a success.409refusals (a cron run holding the lock, an item already published) are worth another try, and the backend refuses a duplicate on its own.Also fixes
promoteRepositoryToNextanswers an unconfigured API with an error payload instead of throwing, and both handlers ignored it — so an unconfigured dashboard toasted "Repository will be published next" after doing nothing at all.Tests
npx vitest run— 26/26. 12 new tests insrc/utils/message-publish.test.tscover the row-merging edge cases (no result yet, outcomes present, Go'snullfor empty slices, a failure with no message, a reported integration the dashboard did not expect, an expected one with no outcome) plus the summary tones.npx tsc -b --forceandnpm run buildare clean apart from two pre-existing errors insrc/hooks/useRepositories.ts:396,411that this branch does not touch.npx eslint srccould not be run: it is broken onmainfor unrelated reasons —Error while loading rule '@typescript-eslint/no-unused-expressions', failing on the untouchedsrc/api/api-configs.ts.Manual check worth doing
repository-mobile-view.