Open a bundle in the TUI as the threads inside it - #337
Merged
Conversation
A bundle posting groups one contact's unseen mail, and its app_url names a
topic only when it holds exactly one unseen thread. For any other bundle the
TUI substituted the posting id for a topic id, which read a topic that does
not exist -- the resource-not-found error screen -- or, on an id collision,
silently opened an unrelated thread and marked the bundle seen.
Enter on a bundle row now opens the bundle: its unseen threads as a list
layered over the box list the way search results are, growing down its Link
cursor, with enter opening a member thread and esc stepping back out. Reply
and forward on a bundle row open the bundle too. The posting-id fallback is
gone everywhere; a non-bundle row that names no thread gets an honest error.
Reads go through the SDK's new Postings().BundleUnseenPage (hey-sdk v0.26.0),
which models GET /postings/{id}/bundles/unseen.
HEY's `bundled` means a posting is filed inside a bundle; the bundle row itself is `kind: "bundle"`. Keying on the flag left every real bundle refused as a row that names no thread. The TUI fixture now goes through mail.NewPosting so the tests exercise the actual mapping.
HEY serves a bundle's unseen threads, so a bundle that has been read through answers none. A bare (empty) list reads as a bug; say what it means instead.
An unread bundle opens its unseen threads; a bundle that has been read through now opens every thread with its contact -- where the web app sends a read bundle -- instead of dead-ending on an empty unseen list. The list is HEY's own, heading and all, read through Contacts().ThreadsPage (hey-sdk v0.27.0), and pages down its Link cursor like every other list.
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
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.
Opening a bundle posting in the TUI failed with the resource-not-found error screen (or worse — see below). Now it opens: the bundle's unseen threads as a list, enter opens a member thread, esc steps back out.
The bug
A bundle's
app_urlnames a topic only when the bundle holds exactly one unseen thread, somail.TopicIDOfanswers 0 for the rest.openSelectedthen substituted the posting id for a topic id and read/topics/{postingID}— a topic that almost never exists, hence the error screen. And since posting and topic ids share an integer space, a collision silently opened an unrelated thread, pointed in-thread reply at it, and marked the bundle seen. The same fallback sat in the list-view reply and forward handlers.The fix
contentListlayered over the box list the way search results are — its own grow-downward lane following theLinkcursor, opened on the shared request lane so failures land on the error screen and stale answers are discarded.r/fon a bundle row open the bundle too. A single-unseen-thread bundle keeps opening its thread directly, as the web app does.Postings().BundleUnseenPage(hey-sdk v0.26.0). Requires the HEY API to serve JSON for a bundle's unseen postings, which is deployed.Closes the TUI half of #156; the CLI-command half is a follow-up now that the SDK operation exists.
Tests
New coverage for opening a bundle, growing it down its cursor, ignoring a stale append, reply-opens-bundle, and the refusal on a topicless non-bundle row. The shared posting fixtures never carried a
TopicID— the old fallback was masking that — so they got real ones.Note for CI
The nix
vendorHashis stale after the SDK pin; the first CI run is expected to fail there and hand back the correct hash, which lands as a follow-up commit.