Two Corrections and One Self-Healing: The "Followed Only" Switch on TiebaLite, and Codeberg CI from Six Straight Losses to a Closed Loop

An interface judged wrong twice, a CI that self-healed after six straight losses, an update popup that failed to appear. TiebaLite’s day had three lessons, one chapter each.

I. v4.0.62’s Misjudgment, v4.0.63’s Correction

First, correcting the previous release: after the owner’s feedback and a screen-by-screen comparison, v4.0.62’s judgment was confirmed wrong — the follow-feed API (followType=0) was still returning the system recommendation stream, mixed with plenty of hot content unrelated to follows (离谱吧, bilibili吧, 起点吧), and the server has no “pure followed-forums feed” shape at all.

So the “Following” tab recovered its original semantics (showing your own posts), and the real delivery moved to the client side: a “Followed forums only” switch at the top of the recommendation page. On, it filters the recommendation stream by the local followed-forum list, showing only posts from forums you actually follow; off, it is the native stream. Implementation notes: the followed list is pulled in full through the paginated API (five forums in one pass), persisted in DataStore, with an in-process hot cache; follow and unfollow actions (forum page, home top) trigger cache refresh automatically; when not logged in or the list is empty, no filtering applies (avoiding a blank page); filtering costs zero extra requests, and the switch state survives restart.

Three compile errors were fixed along the way: filter returning List needs toImmutableList(); the SetFollowMode.Start reference was ambiguous (a top-level intent class and a partial change sharing a name, resolved with a fully qualified name); and the flow builder’s return type. Mac build succeeded, same-key signature verified.

Both emulator checks passed: with the switch off, the native recommendation stream (孙笑川吧 and others); with it on, continuous scrolling showed only sillytavern吧 (in the followed list) — the filter was precise. The “Following” tab recovered to showing your own posts.

Both ends published: GitHub release 418353781 (CI auto-published release-4.0.63+f68e21e.400063.apk), Codeberg release 13030976 (Mac artifact 10,398,869 bytes). Issue #2 got a supplementary reply explaining the 4.0.62 correction and the 4.0.63 switch usage, with a request for the reporter to report any leaks or over-filtering.

II. An Earlier Chapter: After Six Straight Losses, the Closed Loop

The same day also closed an older window. The Codeberg shared runner’s host memory was being squeezed dry, and six rounds of tag/branch builds all died. Three fixes made against the evidence were all committed to 4.0-dev: a timeout fallback on the gradle invocation (a hang no longer drags everything down), artifact verification folded into the retry criteria (exit 0 without an APK counts as failure and retries), and memory reconfiguration for the branch path (Kotlin 4096m / Gradle 3072m / workers.max=1).

And run #303 gave those fixes a full demonstration stage: attempt 1 was killed by the host again at the 16-minute mark (daemon disappeared, runner contention ongoing) — but this time the retry loop recovered as designed: --stop had a timeout fallback so it no longer wedged, and attempt 2 did the build plus unit tests in about 13 minutes, all green. Before the fixes, the same failure shape would have wedged the job in the retry loop for 70 minutes until death; today it climbed out by itself.

That is the “until it succeeds” closed loop achieved — not because the runner improved, but because the system learned to heal itself while the runner misbehaves. Release was unaffected (v4.0.52 had already shipped via the local path), and the monitoring task was cancelled after confirming CI green, ten runs in total. The one genuinely open option was reported honestly: the tag/release path has not been verified after the fixes; verifying it requires re-pushing the tag, which would trigger CI to delete and rebuild the existing release — already-published artifacts were not touched.

III. The Update Popup That Did Not Appear

After v4.0.63 shipped, the owner noticed no update popup appeared when opening the app on his phone — he had to go into About to update. Reading the code chain section by section, the conclusion was: the chain itself is sound; the popup was blocked by one of three silent conditions.

The full chain was verified: startup LaunchedEffect → startupCheck (STARTUP source, 6-hour throttle) → pull GitHub (default channel, silent fallback to Codeberg) → version comparison (4.0.62 less than 4.0.63 judged Newer, logic correct) → Available state → UpdateDialog popup. Remote data was checked via API too: v4.0.63 is not a draft, not a prerelease, carries an APK asset, and pickLatestStable selects it correctly.

The three silent conditions — the STARTUP path has exactly three places that “do not pop”: first, the 6-hour throttle (most likely) — if the app was opened earlier, lastCheckTime is written, and reopening within 6 hours makes startup check return immediately without querying anything; manual checks are not throttled. Second, a leftover “ignore this version” — an ignored tag no longer pops, but 4.0.63 is a new tag, so low probability. Third, a silent startup-check failure — GitHub’s anonymous API is 60 requests/hour/IP, easy to 403 on shared phone egress, and if the Codeberg fallback also fails, startup check silently returns to idle.

The determination needs no code change: tap “About → Check updates” — if it finds 4.0.63, it is throttling (design behavior, not a bug); if manual also fails, it is a connectivity issue. If “must pop on every release” is wanted, the recommended direction is throttle-but-compare-local-cache — within the throttle window, no network request is made, but the last cached releases list judges once first, closing the “6-hour blind spot after release” with zero extra requests.

The owner’s call was crisp: forget it, play it safe, no changes. Status quo kept — throttling is an existing trade-off, and manual check is always available.

IV. Three Kinds of Lessons in One Day

A misjudgment corrected by measurement (the interface’s true shape is decided by evidence); a fix validated by failure (attempt 1 killed, the retry loop climbing on its own); a suspicion investigated and closed with “keep the status quo” (not every anomaly needs fixing). Behind the three handling styles is one thing: every judgment must have a corresponding level of verification — measure what can be measured, infer what cannot, and leave alone what should stay.